Chat Widget Page Speed: What the New INP Metric Means for You

Drop a chat widget on a page and you may change how fast that page reacts to clicks and taps. And since this week, Google judges that reaction with a new metric. So chat widget page speed is something you measure. Not guess. Below: what changed, what the new metric actually watches, why third-party scripts matter, and which checks a site owner can run without calling a developer.

What changed in Core Web Vitals on 12 March 2024?

On 12 March 2024 Interaction to Next Paint replaced First Input Delay as the responsiveness metric in Core Web Vitals. Nobody was caught off guard. According to the web.dev announcement of the change, the Chrome team introduced INP as an experimental metric in May 2022, moved it to pending status last year, and announced its promotion to stable status in advance. Their reasoning? The older measure missed aspects of interactivity that mattered to users.

The other Core Web Vitals stay put. Only the responsiveness measure got swapped, so whatever you already did for loading and visual stability still counts.

What does Interaction to Next Paint measure?

How quickly a page responds to clicks, taps and keyboard input - across the whole visit, not just the first one. INP observes the latency of every interaction, and that latency has three parts: the input delay, the time needed to run event handlers (the code attached to a button or field), and the wait until the browser paints the next frame. The final value is the longest interaction observed, ignoring outliers.

First Input Delay was narrower. Much narrower. It captured only the input delay of the first interaction, which made it a first-impression metric and not much more. Its successor follows the page through its entire lifecycle.

The thresholds sit in the web.dev documentation on INP: a value above 200 milliseconds and below or at 500 milliseconds means a page’s responsiveness needs improvement. The same document notes that, per Chrome usage data, 90% of a user’s time on a page is spent after it loads. Which pretty much explains why reactions after loading deserve their own measurement.

Does a chat widget slow down a website?

It can. Any third-party script competes for the browser’s main thread, and a busy main thread delays the response to a click or tap. The main thread, in plain terms, is the single queue where the browser runs most JavaScript and handles user input. While code is running there, the page cannot react. Simple as that.

And that’s the link between INP and third-party scripts. Chat widgets, analytics, tag managers - they all execute JavaScript on the visitor’s device, and their combined work decides how long a tap waits. The outcome depends on the whole stack of scripts, the page itself and the hardware in the visitor’s hand. So one site’s result says little about another’s.

Think an iframe gets you off the hook? It doesn’t. A widget that opens in an iframe still counts: Google’s documentation states that the metric includes interactions inside iframes, since they are part of the user experience of the page.

How to measure chat widget page speed before and after installation

Record the page’s responsiveness with Google’s own tools before adding the widget. Then repeat the same test afterwards. With a baseline in hand, the whole chatbot script and Core Web Vitals question becomes a comparison instead of an assumption.

1. Check field data for your key pages in PageSpeed Insights and in the Core Web Vitals report in Search Console.
2. Note the baseline values and the date.
3. Add the widget.
4. Run the identical test on the same pages.
5. During lab testing, interact with the page: open the menu, click buttons, open the chat.

A word on the two kinds of data. Field data comes from real visits, lab data from a single simulated one. A lab INP depends on which interactions are performed, and some tools report none at all because they only observe loading. Where the value is missing, Total Blocking Time may be a reasonable proxy - though the documentation is clear that it is not a substitute.

Field data also needs time to accumulate after a change. So don’t judge the widget on day one.

Loading a chat widget without hurting speed: practical checks

Load the script asynchronously, keep only one chat tool on the page, and trim the other third-party scripts you no longer use. That’s the short version. None of these steps requires rebuilding the site, and each one cuts the work queued on the main thread.

• Async or defer loading - the script should not block the page from rendering.
• One chat tool - several stacked widgets multiply the JavaScript without adding value.
• Tag manager audit - remove leftover tags and pixels from old campaigns.
• Selective placement - add the widget only on pages where visitors actually ask questions.
• Re-test - repeat the measurement after every new script.

The Botino widget is added with one script line, so there is a single place to check and test. Running a CMS? The steps for adding a chatbot to WordPress show where that line belongs. Store owners will find the equivalent placement in the guide to adding a chatbot to Shopify.

Why should you test on a mid-range phone?

Because a slower processor takes longer to run the same scripts. Delays you’d never notice on an office laptop show up on a typical visitor’s phone. So grab an ordinary Android device, switch to mobile data and open the site. Tap the menu, fill a form field, open the chat. Watch for any lag between the tap and the reaction.

Then do it again with the widget open and a first message typed. A long greeting or a busy opening state is part of what the visitor interacts with (worth keeping in mind when writing the chatbot welcome message). Field data reflects the devices real visitors use. That’s why it can differ from a desktop lab run.

In my view, chat widget page speed is best treated as a before-and-after measurement, with INP as the number to watch. Your own data, gathered on your own pages, tells you more than any general claim.

FAQ