Back to Insights
Web Development & Marketing4 days agoMark Brazil

Fast to Load, Slow to Respond: The Core Web Vital Most Sites Still Fail

Fast to Load, Slow to Respond: The Core Web Vital Most Sites Still Fail

Your homepage loads in under two seconds. Your developer sent you a green Lighthouse score. And yet customers tell you the site feels slow — the menu lags, the filter takes a beat, the form hesitates before it accepts a click. You're not imagining it, and your speed test isn't lying. It's measuring the wrong half of the experience.

In March 2024, Google replaced First Input Delay with Interaction to Next Paint (INP) as a Core Web Vital. That swap matters more than it sounds. The old metric only measured the delay before the browser started responding to a user's first interaction. INP measures the full round trip — click to visible result — across every interaction on the page, and reports roughly the worst one. It stopped grading the handshake and started grading the conversation.

What INP Actually Measures

When someone clicks a button, three things have to happen: the browser has to notice the input, run whatever JavaScript is attached to it, and paint the updated screen. INP times all three. Google's thresholds are straightforward — 200 milliseconds or less is good, 200 to 500 needs improvement, and anything above 500 milliseconds is poor. Like the other Core Web Vitals, it's assessed at the 75th percentile of real page visits, so a handful of fast sessions on your developer's laptop won't rescue the score.

The other two vitals round out the picture. Largest Contentful Paint (LCP) covers load speed — how long before the main content appears, with 2.5 seconds as the good threshold. Cumulative Layout Shift (CLS) covers visual stability — whether the page jumps around while it's settling, with 0.1 as the target. LCP and CLS are about arriving. INP is about using.

That distinction explains the disconnect between your test results and your customers' complaints. Most marketing sites are tuned for the arrival. Nobody measured what happens on the twelfth click.

Why Your Speed Test Missed It

Lab tools like Lighthouse load a page in a controlled environment and score it. They don't click your filters, open your mega-menu, or fill out your quote form. INP is fundamentally a field metric — it needs real humans doing real things on real devices, including the four-year-old Android phone your trade customers actually use.

So if you're relying on a single lab score, you have a blind spot by design. The data you want lives in Google Search Console's Core Web Vitals report, which draws from the Chrome User Experience Report and reflects actual visits. Start there before you start rebuilding anything.

The Usual Culprits

Poor INP almost always comes down to the browser's main thread being busy when a user tries to interact. A few patterns show up again and again:

  • Third-party scripts stacking up. Analytics, chat widgets, heatmaps, A/B testing tools, ad pixels — each one looked harmless when it was added, and nobody has audited the tag manager since.
  • Long JavaScript tasks that never yield. One function doing too much work in one go blocks every click until it finishes.
  • Heavy framework hydration. Modern JavaScript frameworks can make a page look ready long before it's actually interactive.
  • Oversized DOMs. Thousands of elements on a page — common on filtered product listings — make every update expensive to render.

Notice that none of these are fixed by a faster server or a better CDN. They're fixed by doing less work in the browser.

Treat It Like an Operations Problem

This is where we'd push back on the instinct to rebuild. A full redesign is the most expensive possible response to a problem that's usually caused by accumulated additions nobody owns. The practical sequence is cheaper and faster:

Pull the field data and identify which specific pages are failing, not just the sitewide average. Then profile those pages while actually interacting with them — clicking the things customers click. Nine times out of ten you'll find a small number of scripts or a single expensive handler responsible for most of the damage. Remove what no longer earns its place, defer what can wait, and break up the long tasks that remain.

Then put a governance rule in place: every new script added to the site needs an owner and a reason. Site performance degrades the same way technical debt does — one reasonable-sounding decision at a time.

Why This Is Worth Your Attention Now

Core Web Vitals feed into how search engines assess page experience, so there's a visibility argument. But the better argument is simpler: a form that hesitates is a form that gets abandoned, and a filter that lags is a product someone doesn't find. Interaction quality is conversion quality. You just haven't been measuring it.

If your site tests well but doesn't feel well, we can help you find out why — and tell you honestly whether the answer is a tune-up or a rebuild. Get in touch and we'll take a look at the real data behind your pages.