Your Website Loads Fine. That Is Not What Google Is Measuring Any More.

Most people, when they think about website speed, are thinking about one thing: how long until the page appears. It is the number every speed tool has led with for fifteen years, it is the one clients ask about, and it is the one that gets fixed first.

It is also, increasingly, not the problem.

Google’s three Core Web Vitals are Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint. INP replaced the old responsiveness measure, First Input Delay, in March 2024, which Google announced on its Search Central blog. The first two are about appearance and stability. The third one, INP, is different in kind, and it is the one that quietly fails on sites that everybody agrees feel quick.

What INP actually measures

INP measures the delay between somebody interacting with your page and the page visibly doing something about it. Tap the menu. Tick the checkbox. Hit send on the form. INP is the stopwatch between the tap and the pixels changing.

Google’s published threshold is 200 milliseconds or less, assessed at the 75th percentile of page loads and split between mobile and desktop. For comparison, the other two thresholds are 2.5 seconds for LCP and 0.1 for CLS. Two hundred milliseconds is a fifth of a second, and it is a pass mark, not a target. Google’s own guidance on responsiveness says that if you respond within 100 milliseconds, “users feel like the result is immediate”.

Why a fast site can still fail it

Here is the bit that catches people out. Loading and responding are done by two different mechanisms, and optimising one does nothing for the other.

You can make a page appear in under a second by compressing images, serving WebP, enabling caching and putting the site on decent hosting. Every one of those helps LCP. None of them touch INP.

INP is governed by how busy the browser’s main thread is when the user touches the screen. Every piece of JavaScript on the page competes for that one thread. If a cookie consent script, a live chat widget, a tracking pixel, a slider library and a page builder’s own runtime are all doing work when somebody taps the menu, the tap sits in a queue. The page has already loaded. It looks finished. It is simply too busy to answer. In Google’s own words, the main thread “can only process one task at a time”, and “the browser blocks interactions from occurring while a task of any length is running”.

That is how a site can feel instant on the laptop it was designed on and still hesitate on the phone in your customer’s hand.

The usual culprits, in the order I find them

1. Cookie and consent banners. Almost always third party, almost always loaded early, often one of the heaviest scripts on the page.
2. Live chat widgets. Enormous, and on most small business sites nobody is watching the other end of them anyway.
3. Page builder bloat. Sliders, parallax, animated counters, scroll effects. Each one is a small script. Fifteen of them is not.
4. Tag managers stuffed with forgotten tags. Marketing pixels from campaigns that ended two years ago, still firing on every page view.
5. Plugins that load everywhere. A contact form library loading on all 200 pages because of the one page that has a form on it.

Notice that four of the five are additions, not the original build. Sites do not usually start slow to interact with. They accumulate it.

What a rebuild actually removes

This is the argument for periodically taking a site back to studs rather than patching it. When we rebuilt Smith of Derby, the old build was running nine plugins and twenty six stylesheets on the homepage alone, on a version of WordPress released in December 2018 and a version of jQuery from 2016. The rebuild came out at four plugins and twelve stylesheets, with the text and images preserved exactly. Homepage server response now sits at 0.15 seconds, best of three, from the UK.

None of that was clever. It was subtraction. Every script that is not on the page cannot block a tap.

How to check yours, honestly

Two rules, and both matter.

Use field data, not lab data. A lab test runs on a simulated device with no browser extensions, no background tabs and a perfect connection. It will tell you the page is fine. The Chrome User Experience Report holds real measurements from real Chrome users on real phones, and it is the data behind the Core Web Vitals report in Google’s own Search Console. PageSpeed Insights shows both: read the top section, not the bottom one.

Test the interaction, not the page. Load the site on a genuinely ordinary phone, on mobile data, and open the menu. Tick a box. Type in the contact form. If there is a beat between your finger and the screen, you have found it, and no tool was needed.

That is the same first pass I run on any site before quoting on it, and it is what sits underneath our website speed health check. There is more on the tooling in why GTmetrix is one of the first tools I check.

The point of all this

Nobody has ever left a website because its Interaction to Next Paint was 340 milliseconds. They left because they tapped the menu, nothing happened, they tapped it again, the page jumped, and they decided the business looked amateur.

The metric is just a way of measuring that feeling before your customers have it for you. If you want that looked at properly on your own site, that is exactly what our website design and rebuild work is for.

Questions people ask about INP

What is a good INP score?

Google’s stated threshold is an INP of 200 milliseconds or less, measured at the 75th percentile of page loads and segmented across mobile and desktop.

How is INP different from load time?

Load time measures how long the page takes to appear. INP measures how long the page takes to visibly respond after somebody taps, clicks or types. A page can appear instantly and still respond slowly.

What usually causes a poor INP score?

Too much JavaScript running on the main thread. Chat widgets, cookie banners, tracking scripts, slider libraries and heavy page builders are the usual culprits on a small business site.

Does INP affect my Google rankings?

Google says plainly that “Core Web Vitals are used by our ranking systems”. It also warns that good results in its reports “doesn’t guarantee that your pages will rank at the top of Google Search results”. One signal among many, not a magic lever.

Sources

• Google, web.dev, Web Vitals: LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less, at the 75th percentile of page loads, segmented across mobile and desktop.
• Google, web.dev, Interaction to Next Paint (INP): 200 milliseconds or less is good, over 500 milliseconds is poor.
• Google Search Central blog, Introducing INP to Core Web Vitals: INP replaces FID in March 2024.
• Google Search Central, Understanding page experience: “Core Web Vitals are used by our ranking systems.”
• Google, web.dev, Optimize long tasks and the RAIL model: the main thread, and the 100 millisecond response window.
• Google Search Console Help, Core Web Vitals report: built on Chrome User Experience Report (CrUX) data.
• Weightman Digital’s own build records for the Smith of Derby rebuild, verified against Internet Archive captures of the previous site from July and August 2024.