Improving a third party chatbot widget's performance

Improving a third party chatbot widget's performance

The sad part of third party chat widgets is that it really is up to chat widget providers to improve performance, caring about the performance of their clients' websites and webshops at the same time. But even when they don't, we can make a difference.

In general, being a third party, there almost is no way to improve the performance of third party resources. You could self-host files and maybe tweak them, but you won't benefit from any new third party versions.

Already got through my first blogpost on how to embed chat widgets to improve Pagespeed or Lighthouse score? In this article, I'll explain and demonstrate how to even improve overall UX.

But if this is too cumbersome or not feasible at all, there still are ways to improve your website or webshop's performance without touching third party code itself. This is what I did for several chats at several clients already.

No script means no impact

We all know that no JS is the best. Not from a DX, tracking, website enrichment or user interaction perspective, but at least from a pagespeed, performance and initial UX perspective.

So, let's work from there and things get really simple: Don't load a chat until you are sure a user wants to interact with it. In short, this means you could rebuild the chat-button including it's CSS position, host it yourself and use an onclick event listener to only load the real chat when interacted with. As can be read on Twitter, this is what I did for

Not everybody will use your chat

The real win here is in not loading a whole chat-widget and its resources. Nor inflict all those resources on all of your visitors, despite only 3% up to maybe 10% of them using a chat (Any resources are welcome on this matter, I could only find outdated reports or numbers on user preferences who had the intention to contact a company, so this number is based on other resource-less information).

Some chat widgets are even bigger than the site itself. Talking to you and FreshChat! Zendesk's chat is even know for having a high JavaScript execution time. So let's address Zendesk's Zopim solution today!

Consideration and ethics

Web development also is about ethics. When we talk about accessibility, we aren't just talking about keyboard of screenreader accessibility. But also availability and reliability. Don't waste resources of your users. Especially don't do this if your audience could be paying per kilobyte.

Visualising performance impact of a chat widget

When not having a development background, it can be hard to get your head around Zopim's impact on performance. Besides coming with a solution specifically for Zopim, I also made an animation which will visualize the performance bottleneck. The situation below can be seen within the demo.

The gap between the red square in the top and the green square in the bottom is depicting a moment of main thread blockage. How I created this demo could become a post on its own (or just Google "CSS GPU animations"), but the green square is not impacted by any JavaScript, the red square is. So, when any JavaScript is being executed, it will halt the red square for a moment.

The demo can best be seen with a Zopim V2 key. But even without a key, you will be able to get an idea of the bottleneck of the average chat-widget.

Zopim befor and after demo

A chat can become a UX bottleneck

The gap between those two squares when JavaScript is being executed is a potential UX bottleneck. And we all know Core Web Vitals may be extended, this part of user experience could become part of Core Web Vitals some day. We should keep in mind that the severity of the impact does not only depend on your website, it also depends on:

  • de device that is being used;
  • how performant other third parties are;
  • what are processes are running on a device;
  • et cetera.

You should want to minimize the gap, or even get rid of the gap as users might not be interacting with the corresponding object anyway. Moreover, they could even be doing something else. Or not, if the main thread was blocked by a piece of JavaScript such as a chat widget.

While this code runs, nothing else can happen on the main thread.

Philip Walton

Users might want to interact with another element, being a form field, hamburger menu or a hyperlink. But when some third party (or your very own JavaScript) is blocking the main thread, this could result in user frustration due to:

  • the feeling that the website isn't responding;
  • or is not working properly;
  • and maybe forcing a user to go back to the search results.

Browser crashing due to JavaScript and memory usage

This is something you really do not want your visitors to see when visiting your website:

And once again: it might not be your very own website causing this. But you definitely want to prevent that or reduce the chance of this happening on your very own website.

"But we need pro-active triggers to engage with visitors"

But what good is a static bot, when engagement is important? My take: still try to not load all the resources, and maybe only showing a notification using a small coloured text balloon. And let users click on a chat button on their own initiative.

providers should split up proactive parts vs loading resources for complete chatting interface, as all users will benefit from improved performance

via Twitter

An example: we implemented some user notifications with some websites this way. When the website detects that the user has darkMode or saveData enabled, we just show a notification. Once the user interacts with the bot, we show the appropriate message and give them the option to switch back to light mode, for example.

Ok, so now what?

If you have a static website with no other JavaScript libraries, let alone other third party widgets, then you might want to go for the common tips and async the hell out of it. At least it's a start!
However, this might also depend on the type of audience visiting your website or webshop. What kind of internet connectivity do they have, what devices are they using and are they paying per Kilobyte / Megabyte, for example?

Building your own chat widget

Yeah right, who is foolish enough to start doing this instead? I was, although it started of simple. I will obviously write about this as well soon enough!

Chat providers should step up their game

Just to be clear: some chat providers are already doing a great job. LiveAgent and Soho Desk seem to be doing ok! But in general, chat providers have the responsibility to keep a good performance hygiene and improve overall user experience.

little birdies are telling me that live chat providers claim their tools have no impact on performance. that’s a lie.

Fantastic ms. via Twitter

This way, website and webshop owners have to care less about which third party should be ommited the first in the midst of their own JavaScript framework and other third party widgets.

Just like SEO, might not be one tag or widget that is impacting your performance, it most likely is the sum of multiple tags as well as their priorities.

Happy chatting!