Web Widget Performance FAQs

54 Comentarios

  • 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
  • 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
  • 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

    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
  • 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
  • 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
  • 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
  • Daniel Aron
    Zendesk Product Manager

    Thanks for your feedback James and Will. 

    >>> We're totally baffled that it's not a priority for Zendesk at all

    Performance is absolutely a priority for us, and I think the improvements we've been rolling out are an indication of that.

    >>> Do you have any short/medium term plans to address these serious concerns?

    Yes, the 'lite' concept, where we initially send down a much smaller package for the launcher and then load the rest of the widget when needed is something we are actively considering. That said, it does require a small rearchitecting of the widget and may not be a trivial change for us. For this reason, we're taking our time to understand the impacts to existing functionality and the user-experience.  An example of a potential impact on the UX might be a delay from when the user clicks the launcher to when the content and channel options display in the open widget. Sounds like from your perspective that trade-off is worth it. I’d like to hear from others on this point.

    >>>All that is loaded is the floating icon that toggles between 'CHAT' and 'HELP' as per the availability of our team

    I’m curious to hear more about this. Currently the launcher is “dynamic” in the sense that the icon and label changes depending on agent availability (this happens for both Chat and Talk in the Web Widget). To achieve this we have to make a connection to services on page load rather than on launcher click. How important is this feature to you, as opposed to just a static launcher icon and label that doesn’t indicate channel/agent availability?

    -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
  • 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
  • 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
  • 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
  • Maurice

    Cool solution and thanks for sharing. Can the onLoad be changed to onClick? That's the ultimate work around in my mind. Will check when I'm back in the office.

    0
  • Stephen Neil

    I spoke to soon, and actually ended up changing it to the code below (still substituting "yourkeyhere"):

    <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);
    }
    setTimeout(Chat, 2500);
    </script>

    The onLoad was still loading the script to early and being picked up by Google Page Speed Insights... with this new script, the setTimeout gives just a long enough delay before loading the script.

    You could also trigger the script with a click, yes!

    0
  • James Robinson

    That's brilliant, thank you for sharing that Stephen :) 

    I've set our timeout to 3500 just to be sure it's definitely separated from the page load. On a Pingdom speed test, if it's 3000 or less it still seems to include the widget load in the assessment of the page. I know Pingdom's not the final word in these things, but if they're happy, I'm satisfied that most other things will be too, including our customers.

    With this single change, our simple page loads have dropped from 2.1mb to 1.3mb - a 40% saving!

     

    0
  • 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
  • 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
  • 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
  • James Robinson

    Magento 1.9 user here and looking to implement your code this week. If you'd be willing to share the widget code with the status fetching that would be brilliant.

    0
  • Ctb Devs

    I removed the previous post because it had wrong information. The access to the online status requires an enterprise account so it is not a valid solution and will stop working for us soon.

    Sorry about that :(

    0
  • 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

Iniciar sesión para dejar un comentario.

Tecnología de Zendesk