What is the current package size of the Web Widget (Classic)?
Package | Size (Brotli compressed) | Notes |
Web Widget (Classic) Core | ~475 KB | The web_widget.js and common_vendor.js assets required for the Web Widget (Classic) regardless of which Channels are available. |
With Talk Channel | +~65 KB | The assets required by the Web Widget (Classic) when the Talk Channel is enabled in an account. 55 KB represents the first-time load of the Talk Channel. |
With Chat Channel | +~59 KB | The assets required by the Web Widget (Classic) when the Chat Channel is enabled in an account. |
Per language support | +~5 KB (avg.) per language | The Web Widget (Classic) will only load languages based on the visitor's locale setting. |
Why does the Web Widget (Classic) require this much JavaScript to function?
The Web Widget (Classic) is a powerful tool for embedding customer support into your website, packed with capabilities. You can enable many features and channels for your visitors to Chat with an agent, request a callback through Talk, leave a message and access your Help Center content to self-serve. In addition, the Web Widget (Classic) supports many languages across the globe, and you can customize your Web Widget (Classic) in Admin or via our suite of JavaScript APIs. That said, we acknowledge that we have plenty of room to improve and will continue to prioritize initiatives to optimize package size for any Web Widget (Classic) configuration.
When I embedded the Web Widget (Classic) in my web page I noticed a slower load time. Could the Web Widget (Classic) be slowing my page down?
If you have Chat enabled in your Web Widget (Classic) 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. To learn more, see the article: Optimizing Chat and Web Widget (Classic) performance.
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 optimize the Web Widget (Classic) and Lighthouse will take multiplexing into account when calculating the performance of a web page with the widget embedded.
Does it matter whether I put the Web Widget (Classic) script tag in the <HEAD> or <BODY> of my web page?
For customers concerned about page load performance, we recommend placing the snippet at the end of the <body> rather than the <head>. Even though the snippet script is very lightweight, it’s best to avoid inserting scripts that will block the browser from continuing to render a web page until that script has loaded. Just keep in mind that any scripts that use the Web Widget (Classic) zE JavaScript API must be placed after the snippet script.
Do the Web Widget (Classic) assets get served from a CDN?
Yes, the Web Widget (Classic) assets are served from a Content Delivery Network (CDN) using HTTP/2 to reduce latency. All the assets are accessed via a single origin which means that browsers will only need to open a single TCP connection in order to download the Web Widget (Classic). Visit this page to learn more about the benefits of HTTP/2.
Are the Web Widget (Classic) assets compressed using Gzip?
Yes, the Web Widget (Classic) assets are compressed using Gzip.
Are the Web Widget (Classic) assets cached?
Yes, the Web Widget (Classic) 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 utilized in Talk, or the notification sounds associated with Chat.
What if I use a CSP?
If you use a Content Security Policy (CSP), you must use the latest snippet. For more information, see the developer documentation about CSP support.
5 comments
Michael Lebow
Is there an equivalent page for the new Web Widget? I just installed it and am noticing new performance issues.
0
Miranda Burford
Hi Michael,
We don't have an equivalent page for the messaging Web Widget as yet but I would be keen to hear more about the performance issues you're experiencing. Would you mind sharing more details?
Thanks!
- Miranda.
0
James Robinson
Why is it still the case after literally years of promising performance improvements that the Zendesk chat widget still adds nearly half a megabyte to every single page load? This accounts for a third of our total page size on some pages.
I understand that's valuable to Zendesk as a company to be gathering data from all clients, but all we want is to load the chat button locally with a couple of kb of simple code, then IF a customer chooses to click the chat, then it connects to Zendesk and starts a session. Surely that's not difficult to achieve?
4
Eliazer Braun
it is not (only) about code size.
See this example from a typical light product page
this is a static test without any user interaction
any plans to address this too?
0
Eric Stone
I have to agree that the performance of Zendsk has to do with your servers being just too wimpy and slow.
Every interaction with the site, except for ZenDesk itself, is slow. What I mean by this is your Zchat bot and some parts of the site are super fast, but all customer systems are very, very slow with huge latency.
1. Your DB tier needs an upgrade. Speed. Please.
2. Your web tier also is sluggish.
This is a highly UI/UX customer experience killer Please upgrade your systems. Now.
0