Web Widget Performance FAQs

54 Comments

  • Will Ryan

    I use Zendesk with a number of my clients, and unfortunately, even with these new changes, it is still bloated and far too heavyweight.

    You say that it supports multiple languages... well, load them lazily based off their browser language preference/location rather than pulling down loads of translation files. You say that the web widget has loads of features... well, my client only uses basic chat, not talk or the help centre...so load these other features lazily as and when they are used. Even with these features it makes no sense for a client side library to be multiple MBs in size.

    For a client side piece of code, it is 100s of KB compressed which is just ridiculous...

    On a separate note, if i look at the performance analysis for my site start up, everything on the site is quick but Zendesk has large amounts of processing going on (see screenshot red circles)... for What!?


    I'm also not sure why your embed code does not use async/defer syntax. There is no reason why your script should block the loading of other assets.

    Unfortunately, next time i implement a ticket/help system for a client, it probably won't be with Zendesk. On a mobile network, on a mobile device, performance like this is pretty unforgivable.

    5
  • Miranda Burford
    Zendesk Product Manager

    Hi there!  I’m pleased to provide an update on the progress we’ve made to address Web Widget performance.  Over the last few months, we’ve released a series of improvements to reduce the time it takes for the Web Widget to load on a customer’s website.  

    They include:

    • Changes that streamlined the way we load the various Web Widget assets on a Web page.
    • Reducing the size of larger Web Widget assets.
    • Reducing the number of requests made to Zendesk servers.
    • The Web Widget configuration file is now fetched asynchronously and starts fetching much earlier in our boot sequence.
    • Optimising the way the Web Widget loads so that your customers only download the parts of the Web Widget that they are actively using. This is actively being worked on right now and will be completed in the next month or so. 

    These changes have resulted in a lighter, more performant Web Widget which can be seen in the chart below.  

     

    We’ve measured load times using internal testing methods so exact numbers may vary depending on your widget configuration and other website elements.  The good news is that we’re certainly seeing it trend in the right direction!

    Whilst excited, we recognise that we still have a long way to go until we’re satisfied with the performance of the Web Widget.  We’re making progress, delivering those improvements to you as quickly as we can and we’ll continue to work on it.  

    In the past, a few of you have mentioned that we should be loading assets & features when users are expecting to use them and for the most part, we want the same thing. There are a lot of proactive features and API’s that have existed for a long time and they’re tied up in the initialisation process of the Web Widget.  It’s difficult to untangle them without breaking current customer implementations and we want to avoid that at all costs.  We’ve been working hard to clean this up, along with releasing code splitting changes incrementally so we can deliver these performance improvements to you. 

    Please bear with us as we work through this difficult process and stay tuned for more updates over the coming months!  We appreciate your feedback as always!

    Thanks,

    - Miranda.

    Senior Product Manager, Web Widget

    3
  • James Robinson

    just copying my comment across from the closed beta group as it's not getting any traction there.

    yeah, it's an improvement, but it's a very minor one in the grand scheme of things. The Zendesk widget still accounts for approx 40% of the file size of a typical page on our site and is used by approx 0.2% of our visitors. For those customers it's really important that we have it, but it's a huge compromise for us and we're totally baffled that it's not a priority for Zendesk at all.

    If it's an issue of functionality not being able to be squeezed in, then what we would really like is a 'lite' version whereby all that is loaded is the floating icon that toggles between 'CHAT' and 'HELP' as per the availability of our team. If someone interacts with the button then great, let's load the rest of the files in, but for this to be mandatory and unavoidable for the 99.8% of customers who won't use it is crazy.

    We constantly strive for a better website as does any business, and page load speed is a big factor in how successful we are, but every time we ask ourselves how our site can be better and faster, the answer comes back 'take the Zendesk widget off!'

    2
  • Will Ryan

    I completely agree with James Robinson above. It is nice that you have made this improvement, but there are still vast improvements that can be made. We are performing optimisations on our sites all the time, but a lot of the time, it doesn't matter because the bloated Zendesk chat widget has the biggest impact by a huge margin (despite the changes you have announced today).

    @Daniel Aron: do you have any short/medium term plans to address these serious concerns? It is unacceptable for a modern third party library to be like this, and in future, we would not recommend clients too use Zendesk because of this :(

    2
  • Maurice

    Hmm. It's still hacky to just delay the script, the point of this is to make sure Google doesn't think your site is slow because you're using the widget, and to stop users having to download assets they don't need.

    Page Speed Insights is a rough guide I guess, but I'm sure Google factor in lots of other variables, and Pingdom and other speed tests are more for vanity.

    If they could make the assets download onClick, and then optimize the assets that needed to be downloaded, that would be ideal.

    I'm personally not moving away from my 1kb custom API instant load version until that exists.

    2
  • Zac

    A quick update from us: we have a site that would benefit greatly from the enhanced customer experience enabled by Chat, but we are constrained by the widget loading time and cannot install the widget on the page. It would be extremely helpful to us for some type of "lite" widget to come into play that would allow us to minimize the load on the client when they access the page.

    Alternatively, to circle back on our idea of multibrand "Deployments" from above - if I could create a new deployment of the widget (associated with the same brand as a previous deployment, but with a different server-side configuration) and install the new snippet on my site with only "Chat" and "Contact Form" enabled, that could also potentially reduce the load.

    Ideally, we would be able to combine both approaches to create the ideal scenario - a Lite widget that loads the full admin-defined experience on click, and then a deployment that only loads the resources required for the subject site's experience (which may differ from a deployment installed on another site).

    This is very important to us as the conversation has continued to come up, even after the improvements made by the Web Widget Performance EAP was introduced. The enhancements are truly dramatic and very appreciated, but unfortunately the initial size of the widget before the improvements was so heavy that even after significant updates that reduce the load by a huge margin, the widget is still too heavy to install on some Web properties.

    I would also like to ask if there is a public update to expected timing on the following:

    2
  • Charlie Choiniere

    Hi Daniel Aron,

    Has there been any movement on code splitting? The ZenDesk widget consistently comes up as the biggest offender in terms of payload, parse and execution times when reviewing our lighthouse audits.

    It would be amazing to have a lighter widget to deploy before the holiday season.

    Thanks,
    Charlie

    2
  • Will Ryan

    Daniel Aron Can you give us a candid update on this. It has been a year and 3 months since I first posted here and no tangible improvement in payload size nor performance. A few band aids/workarounds, but nothing significant. It really is very disappointing.

    Do you understand our frustration? It is the slowest thing running on my web applications by a long shot. It just doesn't seem like your team is taking it particularly seriously :(

    2
  • Josh Hanick

    Is it no longer possible to get a "Chat" only version of the include? Both the Chat and Widget includes are the same. We are only interested in loading the Chat items (for English), and the 900kb payload is still very large, especially given our mobile-first audience.

    1
  • Lyndsey Woo

    Hi Will, thanks for your feedback! We're actively working on optimizing the performance of the Web Widget, in particular, lazy loading of translations. Watch this space for updates in the coming weeks! 

    1
  • Ctb Devs

    Hello Daniel,

    Most visitors will not intereact with the Zendesk Widget so the solution to only load the widget when the user interacts with some kind of trigger is something that would be great to have.

    Even though the widget loads quite fast with a good internet connection it is the heaviest element that is loaded for us.

    I know you mentioned that performance tools unfairly flag the performance of the widget (pagespeed goes from 24 to 72 in our case without Zendesk) but they still count for something and could be a concern if search engines take it into account for rankings, advertisements and other things.

    Thank you!

    1
  • Varun Patel

    [solved] I get the solution for this. Thanks to CTB devs for this great idea. I've loaded the zendesk code using ajax after 3 seconds once the page is loaded. Using this way, we bypass all zendesk scripts from the page speed performance tools and get best performance in desktop or mobile.

    1
  • James Robinson

    yeah, it's just a quick bodge to try for now. But maybe not an ideal one... from my google analytics today, site speed is now showing an average increase in page load time exactly equating to the 3.5 seconds delay, so although it's a neat way to get the main page loaded for a customer, it might be detrimental from a google ranking point of view... 

    How is progress on the 'Lite version' of the official widget coming on Daniel? You've stated it's a priority for Zendesk, yet another quarter of a year has passed with seemingly no action.

    Surely this would be a big easy win for Zendesk with minimal effort? I'm still confused at you guys.

    • There's a clear demand for this and the lack of a good solution is damaging UX and rankings of the websites of businesses who choose your product.
    • A Lite version would make a huge performance difference for most sites and performance is a major priority for most online businesses.  
    • It's really not a big job. I'd be baffled if 1 developer couldn't make a solution well inside a week.

    You've stated it's a concern that only loading the Zendesk assets on click might cause a delay to the UX of the widget, but what you seem to be missing is that this delay is instead being added onto the initial page load of every single page view and the perceived speed ranking of the page/site. How is that not 1,000 times worse?

    I don't believe for a moment that Zendesk isn't capable of doing this really quickly if they wanted to and thought it was important. The rest of your software is fantastic. So, again, I'm really confused and disappointed and wonder if there are other factors at play here. Does Zendesk not want to give up collecting the analytic data about our website visitors for example? 

    1
  • Ctb Devs

    Here's something I hacked together in a hour or so: https://codepen.io/anon/pen/KLGGmq (new link at the end)

    What it does:
    - Loads a small HTML, Javascript and CSS to replicate the initial widget markup
    - Registers an onClick event which then loads the Zendesk base script (set the Zendesk Key in the BUTTON element)
    - When the Zendesk scripts finish loading (might be a delay) it will open the widget using the Webwidget API

    What it does NOT do:
    - Does not load the colors you configured in the Zendesk backend (you must change the CSS yourself). I tried to replicate the CSS that is generated
    - Does not check the status of your chat operators (defaults to Chat but you can change the HTML easily and the icon easily)

    Improvements:
    - Add a loader icon when the user clicks to compensate the delay
    - Try to make the static button disappear closer to the moment the widget actually shows
    - Only tested in Firefox and Chromium (Desktop)

    Let me know your feedback and I will make improvements as necessary, add mobile support and whatever. It does not solve the underlying issues but at least it will only load the Widget when the user actually needs it.

    EDIT 1
    Made some tiny improvements (lost access to the previous codepen): https://codepen.io/anon/pen/wbYROv

    1
  • Will Ryan

    It is interesting to see the different ways you are hacking together the loading of the Zendesk library. It doesn't really address the fundamental concerns initially expressed though. Moreover, the solution some have outlined (Load on Click) is not a good idea, as this will break some fundamental Zendesk chat functionality... e.g. if a customer opens a new window when there is an active chat still in progress, or if a Zendesk agent wants to initiate a chat. I might also recommend moving your solutions to a Stack Overflow thread so that your solutions can be scrutinised in a more suitable forum.

    Hopefully @Daniel Aron will look at the efforts that people are going through here, and help motivate them to ramp up his efforts to make a version of the Zendesk chat widget that is fit for use. It has been 5months since our initial chat, and really there hasn't been enough change for me to want to recommend Zendesk in future to my clients. It really must be very lightweight in its initial load, and then load lazily as and when it needs additional bits and bobs for operation.

    Thanks,
    Will Ryan
    Electric Labs

    1
  • Ctb Devs

    Hello Will,

    I certainly agree with you in all your points. It would be great if Zendesk would create a lightweight version of this app at the very least on initial load.

    Regarding your point about active chats there is a key in the browser's localStorage["ZD-store"] that has the following content: "{\"activeEmbed\":\"ticketSubmissionForm\",\"widgetShown\":false,\"is_chatting\":false}"

    I changed the following codepen https://codepen.io/anon/pen/wbYROv to check if these variables are set. If the  is_chatting or widgetShown variables are true it will include the Zendesk scripts normally otherwise it will only do it on click.

    Having the agent initiate chat without the Zendesk scripts being loaded is a different situation and not trivial to achieve.

    Thank you!

    1
  • Daniel Aron
    Zendesk Product Manager

    Hi all,

    Thank you for your continued interest in this topic. We’ve done some proof-of-concept work and have identified a way forward to deliver on a “lite” solution. However, this is not a trivial change for us. Firstly, we need to better decouple the product/channel integrations so they can be delivered independently. We are now making good progress on rearchitecting the Web Widget to achieve this. Secondly, as you’ve already identified, there are popular features such as proactive Chat functionality that rely on connecting to services on page load today, and we’d like to continue to support in conjunction with the “lite” solution. So rest assured this is a pressing issue for us and will continue to work on it as a matter of priority.

    @Zac - implementation of Brotli has been deployed. We saw approx. 4% reduction in compressed package size. The “advanced code splitting” is what I referred to above “decouple the product/channel integrations” which is currently in progress.

    1
  • Will Ryan

    Hi @Daniel Aron,

    This is welcome news. I do hope you take this opportunity to create a truly lightweight widget, free of the current bloat. This includes payload size, as well as javascript performance (which as outlined in my post, shows some serious CPU load as the Zendesk Chat loads up).

    I watch in eager anticipation :)

    Best wishes,
    Will

    1
  • Aleksey Kislov

    Hi all,

    Apologies for the following rant, but current state of web widget is just unacceptable for modern web. For me it's 1.6 MB of web_widget.js, 240 KB of common_vendor.js and 290 KB of chat_vendor.js, which sums up to more than 2 MB of bandwidth for a thing meant to be small. It's a form widget, not a microfrontends-based enterprise SaaS application with IE6 support.

    Code splitting, caching, brotling, deferring are cool and fancy words for sure, but it's just fight against the effect, not the cause. And blaming web performance tools that they are 'not advanced enough' to tolerate a bloated bundle, and 'you should use X because we managed to get higher score in X' is just feels wrong. Lighthouse is here for a reason. 

    The main issue with the code is that it just shouldn't be there. It's hard to investigate the minified bundle for sure, but from what I see there is room for at least deduplication in Zendesk Garden components included in bundle (for example, same Zendesk colors are present 3 times in the code). Also, it could be more the matter of choice, but I believe such universal tools like widgets, which are included in many and many websites, services and applications, should be written in small libraries, and one worthy replacement for React is Preact, which recently hit major X release and has almost identical API to React, but is 10 times smaller.

    Don't get me wrong, I'm not a hater (and not a PWA fanatic either), I've been developing with Zendesk for a while and really see many improvements you guys made recently. Zendesk Garden is great. React Components along with all the splitting and TypeScript is a true relief. And I know what it means to modernize a project which is being used worldwide and has that amount of customers. It's not that easy. I just hope it will be done properly and in the near future, and everyone will be happy with the result.

    Thanks.

    1
  • James Robinson

    Hi, thanks for an update, but sad that it doesn't make any difference for the general widget when our chat team isn't online. So I'll go back to my bodged time delay option as that seems to work best whilst we wait for a more comprehensive solution.

    If anyone else is interested in giving it a go, here's what works for us. It just delays the load by 3.5 seconds, but it seems that's enough to stop impacting load times:

    <!-- Start of Zendesk Widget timeout script -->
    <script>
    function Chat(){
    var script = document.createElement("script"); //Make a script DOM node
    script.id ="ze-snippet"
    script.src = "https://static.zdassets.com/ekr/snippet.js?key=put-your-key-in-here";
    document.head.appendChild(script);
    }
    setTimeout(Chat, 3500);
    </script>
    <!-- End of Zendesk Widget timeout script -->  

     

    1
  • Zac

    Hi Daniel,

    I am very interested in the approach you are taking to code-splitting. Some of us with more complex implementations may not be able to fully realize those benefits. I may have multiple deployments of a Web Widget for a single brand - for example, one to serve a guest experience through a commerce page, and another to serve a guest experience through a marketing page. On the commerce page, I may enable Talk, while I would disable it on the marketing page.

    To do this, I will have to enable Talk for the entire brand, then mask it using the JS API. That means the components will still load on every site / deployment of my widget, even though I only want to use them on one deployment and not on the other.

    I think the easiest way to control this from the perspective of your admins is to allow us to create multiple "Deployments" of a widget for a single brand, where we customize what features will be available for a given deployment directly in the admin panel. That way, I can create a Commerce deployment, and a Marketing deployment, each with its own snippet and its own set of enabled channels. Adding it to my page in this way would enable me to fully realize the benefits of code-splitting.

    Taking this a step further - I would be glad if I could change more of the settings for the Web Widget directly in the admin panel, rather than using the JS API. I would be glad to elaborate on our use cases if it's interesting to you.

    Thanks for your hard work around this!

    0
  • Daniel Aron
    Zendesk Product Manager

    Thanks for you feedback Zac! Your idea of setting up multiple deployments aligns closely with some of our future thinking underway.  We want to enable customers to create targeted configurations of the widget and to do it via an Admin interface.  I'll be sure to reach out to you to get your thoughts when we have something to share.

    0
  • Sebastiaan

    Hi Daniel,

    Currently, "the Web Widget displays text in the end user’s language, based on the language of their browser". It would be rather brilliant however if this were to be the same language as the one selected in the footer. If I change the language of the help center to a different language, I would like the Web Widget to detect this as well

    In case other users may experience this problem as well, you can use this in your header.hbs:

    <script type="text/javascript">
    var pos = window.location.href.search('hc/')+3;
    var lang =window.location.href.substring(pos,pos+2);
    if (lang == 'en') {
    lang = 'en-US'
    }
    zE(function() {
    zE.setLocale(lang);
    });
    </script>

     

    0
  • Maurice

    Has this update already been pushed? I just did some tests, it definitely seems faster and lighter than when I last checked, but still isn't fast enough for me to implement it on my sites. 

    0
  • Will Ryan

    Hi Lyndsey, thanks for getting back to me on this thread. Any updates to performance, would be great to here about it on this thread. Lazy loading translations would certainly be a decent start. But there appears to be other major issues with the web widget, so i hope this can improve in the not too distant future.

    0
  • Daniel Aron
    Zendesk Product Manager

    Hi Will, we recently released translations optimizations and have updated this FAQ article to reflect that. We'll also be posting an announcement soon with more detail on this and other improvements.

    0
  • Daniel Aron
    Zendesk Product Manager

    Here's the translations performance improvement announcement

    0
  • Maurice

    What Ctb said is definitely the best-case scenario, an on-demand button with a 1 to 2 second loading gif would solve everyone's problem. I wonder if it could be hacked by loading an iFrame onclick? Hmm. 

    0
  • Stephen Neil

    Varun, 

    Would you be able to detail out how you did it? I would like to implement this into my site... I am so close to ending things with Zendesk over this...

    0
  • Stephen Neil

    After struggling with this issue for more time I care to admit... I found the solution.

    Put the following code into your header and swap out your Zendesk key in the snippet:

    <script>
    function Chat(){
    var script = document.createElement("script"); //Make a script DOM node
    script.id ="ze-snippet"
    script.src = "https://static.zdassets.com/ekr/snippet.js?key=YOURKEYHERE";
    document.head.appendChild(script);
    }
    if (window.addEventListener)
    window.addEventListener("load", Chat, false);
    else if (window.attachEvent)
    window.attachEvent("onload", Chat);
    else window.onload = Chat;
    </script>

    Zendesk Chat now loads after the page is finished loading and it no longer effects page speed scores

    0

Please sign in to leave a comment.

Powered by Zendesk