I wrote my own chatbot + livechat and this created quite some fuzz on LinkedIn. I even received swear words, luckily just for chatbot testing purposes 😅. But let's talk about the harm of chat bots such as Zopim (Zendesk), and how I visualized this.
Beside my (Dutch) LinkedIn post, a Twitter thread on chat performance was initiated around the same time.
Visualizing performance and real UX impact of a chat
Let's start with a simple demo to get you hooked, even if you aren't a developer. Every piece of JavaScript will block the main thread. It is imporant that such JavaScript won't block the main thread for too long. And this is where chat performance can go wrong.
When opening my chatbot, you can see that the red top square is being freezed, as your browser now has to take care of executing the script. But what if the script was executing itself while the user tried to do something else, or the main thread and thus red square was freezed for a longer period?
There are some common tips when it comes to reducing the impact of a chat on your Pagespeed Insights or Lighthouse performance score. So, time for some tips to (not) optimize your chat and (not) improve your pagespeed score.
Using async to embed your third party chat
When implementing a chat provider, you often get to copy and paste a JavaScript snippet to embed a chat within your website. Embedding could be done via Google Tag Manager, or directly within the source of your website. Below, you can see an example of a Zopim v2 snippet.
This snippet will be provided with an async attribute for the JavaScript file. This can be seen by the async=!0 part, resulting in true and thus becoming an asynchronous script file. This is obviously a good start, as it tells the browser to not block the parsing and rendering process of your visitors' browser while the file is being fetched.
Time to Interactive might not improve
While using async will definitely help improve your First Contentful Paint for example, you will notice that your Time to Interactive metric might not improve, or not improve as much as you hoped for. The reason is while async allowed the browser to do other task while downloading the chat's resources, the execution of the chat resources is just being pushed back.
Best practices besides using async
Do note that an asynchronous script file will still interrupt the browser once the script file has been fully downloaded. Third party providers want them to be executed as soon as possible, but this might not always be the best for your website performance nor user experience, because it will now be executed somewhere in time without being able to tell when exactly. Maybe even when the user just tried to interact with your slideshow or hamburger menu. So:
- Put your chat snippet in the end of your HTML file, so it won't get in front of other, probably first party or more important files and tasks;
- Some chat widgets have bundled files, which might block the main thread for a longer consecutive period, increasing Total Blocking Time and Time to Interactive;
- Even when not being bundled, it might become a bottleneck as well as the browser now has to wait before the chat's other resources are loaded and executed.
Using the proper Google Tag Manager trigger
When using Google Tag Manager, you can make a difference as well. You should use the right Google Tag Manager trigger, being Window Loaded instead of Page View or DOM ready. Screenshot below originates from a Performance.now talk by Simon Hearne.
Using Window Loaded as a trigger type, you are kind of achieving the same as putting the file download and execution at the end of your HTML file, as described above. You want your first party resources such as CSS, images and iframes to be executed before (most) third party resources.
Window Loaded: Fires after the page has fully loaded, including any embedded resources such as images and scripts.
Google Support on PageView triggers
Delay the chatbot with 5 seconds
Some will advice you to delay the loading of your chat with 5 seconds. This will improve your synthetic Lighthouse score for sure, as Lighthouse will stop polling the browser's thread after 5 seconds. Obviously, anything that is being executed 5 seconds after the last idle moment won't be detected by Lighthouse.
However, if we learned anything from the Core Web Vitals, it is that not only your users but also Google and even GTmetrix thinks real UX is more important than lab data or synthetic testing.
Loading a chat after 5 seconds could still pose a risk as described below and visualized in the demo. As a result, this should be seen as a work-around for synthetic testing instead of a real solution.
Really improving the performance and UX
People who say "Don't use a [insert third party] then" are quite right. But we all know we don't live in different times. How I optimized existing chat widgets, such as Zendesk's Zopim, can be read in a new blogpost about improving a third-party chatbot widget's performance. It even comes with a (code) example which can be used.
