Web Widget Performance FAQs

47 Comments

  • Will Ryan
    Comment actions Permalink

    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
  • Charlie Choiniere
    Comment actions Permalink

    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
  • Daniel Aron
    Comment actions Permalink

    Hi Charlie, thanks for your feedback. The code splitting work is actively in progress. I don't have an ETA to share yet for when we can release a  lighter widget, but i'll provide an update when I can.

    0
  • Aleksey Kislov
    Comment actions Permalink

    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
  • Daniel Aron
    Comment actions Permalink

    Hi Aleksey, thank you for you candid and detailed feedback. 

    In regards to your comment

    | The main issue with the code is that it just shouldn't be there.

    This is a very astute observation and you are correct with most of what you’ve found. We are currently in the process of migrating across all of our components to use css-in-js and also currently upgrading all of our internal Garden components to do the same thing, so right now there is a little bit of duplication happening with regards to styles and colours.

    As we continue to work on this we have also begun to dynamically load content for the different channels that we provide, the talk and help_centre channels are currently loading this way in production and we are actively working on loading the remaining channels in the same way. We intend to deliver some significant reductions in package sizes and improvements to performance in the coming months ahead.

    0
  • Daniel Aron
    Comment actions Permalink

    I’m pleased to announce we have released a new Web Widget js api setting called connectOnPageLoad which can be used to optimize performance when you have Chat enabled. Using this setting you can defer the Chat connection until your customer interacts with the widget.  

    Here’s the announcement

    Learn more about this feature

    This release is the first step in a focussed program of work towards the goal of delivering the “lightweight widget” discussed throughout this comment thread. 

    I look forward to hearing how you go with using connectOnPageLoad. Has it made a difference to the performance of your Web Widget or web page?

    0
  • MH Berk
    Comment actions Permalink

    so this only works if you have chat enabled and not just standard widget for ticket entry? 

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hey MH Berk,

    If you're referring to the announcement posted by Daniel in the previous response, then yes this will only work if you have Chat enabled within the web-widget.

    Let me know if you have any other questions!

    0
  • Ctb Devs
    Comment actions Permalink

    Good to know about this new development. I will test it to see if it has any improvement over the solution I posted a few months ago (https://codepen.io/developersctb/pen/wbYROv). It also loaded the widget only when the user interacted with it.

    0
  • James Robinson
    Comment actions Permalink

    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
  • Sergio Pinilla
    Comment actions Permalink

    Hi, I would like to know if the connectOnPageLoad option can be used with the Lite version of the product.

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hey Sergio,

    If you're using Chat lite you should still be able to use that option. As far as I know, this option is not limited to what plan level you're on.

    Let me know if you have any other questions!

    0
  • Sergio Pinilla
    Comment actions Permalink

    Thank you, Brett,

    I was asking because I had tried to use it and it didn't work, I thought it was because the Lite version couldn't.

    I added the following code in the footer of all my pages and I can't get it to work:

    <script type="text/javascript">
    window.zESettings = {
    webWidget: {
    chat: {
    connectOnPageLoad: false
    }
    }
    };
    </script>

    <!-- Start of xxxxxxx Zendesk Widget script -->
    <script id="ze-snippet" src="https://static.zdassets.com/ekr/snippet.js?key=xxxxxxxxxxxxxxxxxxxxxx"> </script>
    <!-- End of xxxxxxxx Zendesk Widget script -->

    The only difference is the code that sets the connectOnPageLoad option to false. With this code, the chat does not change its status when we are online. If I remove that code, it starts working correctly again.

    This is my development page, if you can help me: https://desarrollopapelstore.factoriadigitalpremium.es/

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hey Sergio,

    I'm going to create a ticket on your behalf so our Customer Advocacy team can look into this for you. You'll receive an email shortly stating your ticket has been created.

    Cheers!

    0
  • David Coleman
    Comment actions Permalink

    Can anyone comment on the performance of the web widget when using suppress property?

    For "signed-in" users, we are using the web widget with Talk "Request a callback", Chat, Contact Form, and the chat property of connectOnPageLoad=false and it loads rather fast under these conditions.

    However, when our customers aren't "signed-in" we call another nearly equal function on page load that suppresses all parts except the Contact Form and it takes 5-6 secs to load. Does suppressing force it to release cache or something?

    Any feedback is appreciated!

    0
  • Daniel Aron
    Comment actions Permalink

    David Coleman In the second case (not signed in) are you still using connectOnPageLoad=false?

    0
  • David Coleman
    Comment actions Permalink

    Thanks mate. I actually discovered that I wasn't using 'updateSettings'. Once I made the change, things updated much more quickly! = )

    0

Please sign in to leave a comment.

Powered by Zendesk