Google measures the real-world speed of your website using three scores it calls Core Web Vitals. One of them, INP, is the one most sites fail. Around 4 in 10 sites are over the limit. If yours is one of them, visitors feel it as a site that lags when they tap.
The short version
- INP stands for Interaction to Next Paint. It measures the delay between a user tapping or clicking something and the screen visibly responding.
- Google’s target is 200 milliseconds or less. Between 200 and 500 needs work. Over 500 is poor.
- The score is based on real visits to your site over the past 28 days, not a single lab test.
- The usual cause is too much JavaScript running at once. On small sites, that usually means too many plugins and third-party scripts.
What INP actually measures
Think about the last time you tapped a menu button on a phone and it just sat there for a beat before opening. That pause is what INP captures. It times the gap from when you interact with the page to when the browser can next show you a visual change on screen.
Google watches every click, tap, and key press during a visit and reports close to the worst one. So one janky interaction can drag your score down even if the rest of the page feels fine. The number you are graded on is the 75th percentile of real visits, which means 3 out of 4 of your visitors had that experience or better. INP replaced an older score called FID in 2024. FID only measured the very first delay on a page. INP measures the whole visit, which is harder to game and much closer to how the site actually feels to use.
Where the score comes from
There are two kinds of speed data, and people mix them up constantly.
- Field data is real visits from real Chrome users, collected over a rolling 28-day window. This is what Google actually grades you on. A brand-new or low-traffic site may show “not enough data,” which means Google is not judging it yet.
- Lab data comes from a tool like Lighthouse running one test on a simulated phone. It is useful for finding and fixing problems, but it is a lab guess, not your grade.
Because field data is a 28-day average, a fix you ship today takes a few weeks to fully show up in the score. That lag is normal. Do not panic if the number does not move the next morning.
Why it matters beyond the score
Search. Core Web Vitals are a ranking signal. They are not the biggest one, but when two pages are close, the faster page has an edge. Google has published case studies linking better vitals to lower bounce rates and more conversions.
Money. A site that feels slow to respond loses people at exactly the wrong moment: mid-tap, reaching for the “Add to cart” or “Book now” button. The delay does not have to be long to make someone give up. It just has to be long enough to feel broken.
What pushes a small site over the line
Poor INP is almost always about JavaScript. JavaScript is the code that makes a page interactive. The browser can only do one thing at a time on its main thread, so when a big script is running, your tap has to wait in line behind it.
On a typical small-business site, the culprits are:
- Too many plugins. Each one may add its own scripts that load on every page, even pages that do not use the feature.
- Third-party scripts. Chat widgets, popup tools, review badges, analytics, ad and tracking pixels, embedded social feeds. This is code you do not control, running on your page and competing for the browser’s attention.
- Heavy page builders. Some drag-and-drop builders ship a lot of extra code to support every feature, whether your page uses it or not.
- Big, messy pages. The more elements on a page, the more work the browser does to update the screen after every interaction.
A real example: a home page with a chat widget, a popup builder, an Instagram feed, two analytics tools, and a cookie banner can spend half a second of every tap just running other people’s code. Remove the widget nobody uses and defer the Instagram feed, and the same page can drop back under 200 milliseconds with no visible change to the design.
How to check your own site
- Go to PageSpeed Insights and enter your URL. If Google has enough real-user data, it shows your INP near the top, in green, orange, or red.
- Check a few page types: home, a service page, and a contact or checkout page. They can differ a lot.
- Check on mobile. That is where most people visit and where slow interactions hurt most.
- In Google Search Console, the Core Web Vitals report shows how many of your pages pass or fail, grouped so you can see patterns.
What actually fixes it
The fixes are not exotic:
- Remove plugins and scripts you do not need. Audit the list honestly.
- Load third-party scripts later, after the page is usable, or only on the pages that use them.
- Cut a chat widget you get one message a month from.
- Simplify overloaded pages and reduce the number of elements.
- On a heavier site, move off a bloated builder to a leaner setup.
In most cases none of this requires a full rebuild. It requires someone willing to go through the list and cut.
How I can help
A free website health check includes your Core Web Vitals across all three scores, checked on your key pages, with the specific scripts and plugins that are hurting you named.
Most speed problems come off a fix list: trim scripts, defer what can wait, tune caching, compress images. If your site is built on something that is heavy by design, we talk about a rebuild on a lighter foundation. Speed is built into every site I make, not added at the end.
Sources
- web.dev (Google), “Interaction to Next Paint (INP)”
- web.dev (Google), “Web Vitals”
- web.dev (Google), “Optimize Interaction to Next Paint”
- Google, “PageSpeed Insights”