See how we reduced the impact of our chat widget on Google Lighthouse scores, improving site performance by upwards of 14 points through simple fixes.
Strong website performance is no longer a “nice to have” metric — it’s a critical part of your user experience.
Slow loading times and laggy pages tank conversion rates. They serve up a negative first impression of your brand and can push even your most loyal customers to greener pastures.
When we found out our chat widget had started negatively impacting our customers’ Google Lighthouse scores — an important performance metric — we immediately started searching for a solution.
Live chat is a notoriously resource-intensive category, but we were able to cut our entry point bundle in half using the process I lay out in this article. As a result, we reduced the Lighthouse score impact to just one point, compared with a control.
Here’s what we’ll cover:
- Live chat widgets: form and function
- Initial negative impact of our chat widget
- Analysis and bundle reorganization
- Results and impact of the bundle reorganization
- Preventing future regression
Form and function of live chat widgets
Chat widgets are small apps that allow visitors to get quicker results without leaving the webpage they’re on. The chat window usually sits in the bottom corner of the screen, when open.
Here is an example:
Live chat is especially helpful on ecommerce websites, because retail shoppers expect quicker responses. Repetitive questions involving order status, return policies, and similar situations are easily resolved in chat, and it can also provide a starting point for more complex inquiries.
Because merchants make up the bulk of our customers at Gorgias, our live chat feature is a major part of our product offering.
Our live chat feature is a regular React Redux application rendered in an iframe. It may appear simple and limited, but its features extend beyond simple chat to include campaigns, a self-service portal and widget API.
We implemented code-splitting from the beginning to reduce bundle size, leaving us with the following chunks:
- An entry point chunk, which contained React, Redux and other essential modules
- A chat window chunk
- A chunk with a phone number input component
Unfortunately, that initial action wasn’t enough to prevent performance issues.
Initial negative impact of our chat widget
We started hearing from merchants that the chat widget was impacting their Google Lighthouse scores, essentially decreasing page performance. As I previously mentioned, chat widgets generally have a bad reputation in this regard. But we were seeing unacceptable drops of 15 points or more.
To put those 15 points in context, here are the Google Lighthouse ranges:
- 0 to 49 – Poor
- 50 to 89 – Needs improvement
- 90 to 100 – Good
So if you had a website with 95 performance points, it was considered to be “good” by Lighthouse, but the chat could take it down to “needs improvement”.
Of course, we immediately set out to find and fix the issue.
Analysis and bundle reorganization
There were several potential causes for these performance issues. To diagnose them and test potential solutions, we prioritized the possible problem areas and worked our way down the list. We also kept an open mind and looked in other areas, which allowed us to find some fixes we didn’t initially expect.
The initial entrypoint file was 195kB gzipped and the entire bundle was 343kB gzipped. By the end, we had reduced those numbers to 109kB and 308kB respectively.
Here’s what we found.
Checking for unnecessary rendered DOM elements
First, we opened a test shop with chat installed and tried to find something unusual.
It didn’t take long: The chat window chunk was loaded and the corresponding component was rendered, even if you didn’t interact with the chat. It wasn’t visible, because the main