Your homepage scores green. The hero image appears almost instantly. And yet people still describe the site as "slow." They click a filter and nothing happens for a beat. They open a dropdown and it stutters. They hit submit and wonder whether it registered, so they hit it again.
That gap between load speed and feel is where most sites lose money, and until recently the standard metrics barely captured it.
What Google Changed
In March 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital. The distinction matters more than the acronym swap suggests.
FID measured only the delay before the browser began processing your first interaction. It ignored how long the work took and ignored everything after that first tap. A site could feel miserable to use and still pass.
INP measures the full round trip — from the click to the moment the screen visibly updates — and it looks across interactions throughout the visit, not just the first one. Google considers 200 milliseconds or less good, and anything above 500 milliseconds poor, measured at the 75th percentile of real visits. In plain terms: three out of four people should get a response that feels immediate.
Why Your Lab Score Lies to You
Run Lighthouse and you get a page-load simulation with no human in it. Nobody clicks anything. So the tool cannot meaningfully report INP — it can only flag conditions that tend to cause it.
INP is a field metric. It comes from real people using real devices on real networks, which includes the mid-range Android phone with fourteen browser tabs open. That device is doing the same JavaScript work as your MacBook, with a fraction of the headroom.
If you are judging site performance on a lab score alone, you are grading the version of your site that nobody uses.
Where the Delay Actually Comes From
Browsers do most of their work on a single main thread. When that thread is busy, it cannot respond to input. Long tasks block clicks. The usual culprits are boringly consistent:
- Third-party tags — chat widgets, heatmaps, ad pixels, A/B testing scripts that block rendering while they decide what to show
- Page builders and themes that ship every feature's code on every page, used or not
- Enormous DOMs from stacked sections and nested containers, which make every style recalculation expensive
- Client-side filtering or search that re-renders a large list on each keystroke
- Analytics and consent tools firing synchronously on interaction instead of after it
Notice how many of those were added by a marketing decision rather than an engineering one. Every tag someone installed "just to test" is still there, still costing milliseconds on every click.
The Pages That Matter Are the Interactive Ones
Here is the business translation. Your slowest-feeling pages are almost always your highest-intent pages: product filters, configurators, booking flows, quote forms, checkout. These are the pages where users interact the most, which means they are the pages INP punishes hardest — and the pages where hesitation turns into abandonment.
A brochure page that loads in a blink and a quote form that lags on every field is a site optimized in exactly the wrong place.
Fix Order That Doesn't Require a Rebuild
Start with subtraction. Inventory every third-party script and ask who owns it and what decision it informs. Most sites can remove several without anyone noticing. This is the cheapest performance work available and nobody wants to do it.
Then defer. Scripts that support secondary features — chat, surveys, personalization — rarely need to load before the user has done anything. Load them after interaction or on idle.
Then break up the work. Long tasks can be split so the browser gets a chance to respond between chunks. Heavy filtering and search often belong on the server rather than in the browser.
Finally, acknowledge the click. If an action genuinely takes time, render something immediately — a disabled button, a spinner, a state change. Perceived responsiveness is part of the metric, because INP stops counting at the next paint.
When It Really Is the Platform
Sometimes the honest answer is that the theme, plugin stack, or builder has a floor you cannot get under. If every optimization gets undone by the next template update, you are maintaining a workaround, not a site.
That is a rebuild conversation — but it should be a decision made after measurement, not instead of it. We have seen teams spend a full redesign budget and land on the same interaction lag, because the new site inherited the same tag stack and the same client-side patterns.
Start With Field Data
Before you scope anything, get real-user measurement in place and find out which templates and which devices are failing. The fix is usually narrower and cheaper than a redesign, and it compounds — faster interactions help conversion and search visibility at the same time.
If your site loads fine but feels slow, or you are weighing a rebuild against targeted work, reach out to Infraxio. We will look at the field data with you and tell you which one you actually need.