Web Widget Performance FAQs
If you have Chat enabled in your Web Widget and want to optimize for page performance, you can consider using the connectOnPageLoad api. This should decrease the time taken to display the widget launcher and improve page load scores in tools like Google Lighthouse. Learn more.
What is the best tool to monitor page load speed for my website?
We recommend using Google’s Lighthouse tool that is available by default in the audit tab of developer tools. Lighthouse has very good coverage of new features available in modern web browsers like Google Chrome. We rely on features like HTTP/2 multiplexing to optimise the Web Widget and Lighthouse will take multiplexing into account when calculating the performance of a web page with the Widget embedded.
Yes, the Web Widget assets are individually versioned and long-term cached for up to a year. They’re cached both privately on end-user browsers, and publicly on CDN edge servers. Some assets required for the Widget are unlikely to change between Widget versions, and will be cached independently. This means those assets will be retrieved faster from cache the next time the browser needs them. For example, the country code flag icons utilised in Talk, or the notification sounds associated with Chat.
We’re currently prioritising investment in performance and expect to deliver some major improvements throughout 2020.
- As a first step, we recently released the connectOnPageLoad setting to enable you to optimize for performance when you have Chat enabled. Learn more.
- We’ve created a smaller set of core Web Widget assets and started to optimise the way the Web Widget loads so that your customers only download the parts of the Web Widget that they are actively using.
What's still to come?
- We’re making progress on code-splitting, so that only UI assets for the channels you have enabled are sent to the browser. We have already split Talk, Help Center, and Support are working next on Chat and Answer Bot.
- We’re reducing the amount of time it takes for the Web Widget launcher to display by decoupling it from other assets.
- Further optimisations to the way that Talk loads within the widget, plus more.
-
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.
-
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! -
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!
-
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.
-
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 :(
-
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.
-
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.
-
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.
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?
-
so this only works if you have chat enabled and not just standard widget for ticket entry?
-
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!
-
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.
-
Hi, I would like to know if the connectOnPageLoad option can be used with the Lite version of the product.
-
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!
-
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/
-
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!
-
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!
-
David Coleman In the second case (not signed in) are you still using connectOnPageLoad=false?
-
Thanks mate. I actually discovered that I wasn't using 'updateSettings'. Once I made the change, things updated much more quickly! = )
-
Hi Will Ryan,
Thanks for your message. I'm jumping in here on behalf of Dan. I want to start by saying that we definitely understand your frustrations and are taking performance within the Web Widget very seriously. We have a program of work related to performance that the team has been working hard on (and will continue to do so) and we are very close to announcing the first batch of improvements. These include changes to the way we streamline the various widget assets, smaller core assets, plus more. This will be a great start to improving performance. We've seen results trending in the right direction but do want to acknowledge that there is still more work to do!
You can expect an update here over the next few weeks.
Thanks,
- Miranda.
Senior Product Manager, Web Widget
-
Hi Miranda,
Bit of a side note to your last post. Whilst it's great that the Web Widget team is working on performance improvements. I'm also curious as to when we will see some more functionality improvements with the web widget. i.e closing the current gap you have with the ticket forms in web widget.
The ticket forms feature doesn't support all of the ticket fields which Zendesk offers; therefore it renders the web widget half useless to enterprise customers who NEED to leverage the use of fields such as date pickers, multi-select, and regex fields.
If would be nice to see if the team can start really plugging those gaps which have been sitting waiting for a long time to be built into the web widget. No doubt there might be some better uptake in enterprise customers utilizing the web widget more for there needs.
Best,
Amie
-
Hi Amie B,
Thanks for your feedback (and no worries at all about the side note).
At this stage, unfortunately, we don't have any concrete plans to introduce new field types within ticket forms. Date pickers, multi-select and regex fields have come up in the past and we do hope to offer more choice within our ticket field options in the future. But as you can imagine, we're always making difficult trade offs in terms of what we can work on at any given time. I do agree that this is an area where we can improve and offer greater flexibility.
I'll definitely log your feedback and will reach out to you when there's any news. We appreciate your open & honest feedback!
Thanks,
- Miranda.
-
Hi,
will this last update effect Google Lighthouse measurements ? For some customers this is important to get good scooring from Google.
Regards
Mikael B
-
Hi Mikael Bohlin,
Yes, the last update should have improved Google Lighthouse performance measurements. We were reluctant to give specific numbers as these can vary depending on a number of factors. Based on our own testing methods, we're confident that these numbers improved with the last update.
Hope this helps!
- Miranda.
-
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?
Iniciar sesión para dejar un comentario.
54 Comentarios