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.
Table of Contents
- No script means no impact
- Visualising performance impact of a chat widget
- Ok, so now what?
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).
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 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.
A chat can become a UX bottleneck
- de device that is being used;
- how performant other third parties are;
- what are processes are running on a device;
- et cetera.
While this code runs, nothing else can happen on the main thread.Philip Walton
- 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.
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 performancevia 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?
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
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.