Core Web Vitals in 2026: Why INP Broke Scores That Used to Pass, What Actually Fixes Them, and How Speed Feeds AI Search
- Internet Pros Team
- August 24, 2026
- Web Design
A lot of websites quietly stopped passing their performance check about two years ago, and most of their owners never found out. Nothing broke. Nothing looked different. Google simply retired the metric that was easy to pass and replaced it with one that measures something visitors actually complain about: the delay between tapping something and seeing the page respond. In 2026 that metric, Interaction to Next Paint, is where nearly every failing site fails.
The Three Metrics That Count in 2026
Core Web Vitals is Google's attempt to reduce page experience to a small number of things that can be measured on a real visitor's device. There are three, and each one stands in for a different complaint.
Largest Contentful Paint answers "when did the page look loaded?" It marks the moment the biggest visible element - usually a hero image, a heading, or a banner - finishes rendering. Cumulative Layout Shift answers "did the page move while I was reading it?" It accumulates every unexpected jump caused by content arriving late. Interaction to Next Paint answers "did the page respond when I touched it?" It records the full delay from a tap, click, or keypress to the next frame the browser paints, and it reports roughly the worst interaction of the entire visit.
That last definition is the one that changed everything. The metric INP replaced, First Input Delay, measured only how long the browser waited before it began handling your first interaction. It ignored how long the handler took and whether anything appeared afterwards. Around 96 percent of sites passed it. It was, in practice, a metric that measured almost nothing.
First Input Delay asked whether the browser picked up the phone. Interaction to Next Paint asks whether anyone said anything useful once it did.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | Time until the largest visible element renders | 2.5s or less | Over 4.0s |
| INP | Delay from interaction to the next painted frame | 200ms or less | Over 500ms |
| CLS | Total unexpected layout movement, unitless | 0.1 or less | Over 0.25 |
One detail in the scoring catches people out constantly: you are graded at the 75th percentile of real visits over a rolling 28-day window. Your own device on office fibre is not the test. A quarter of your audience is allowed to have a bad time; the other three quarters are not. And because the window is four weeks long, a fix deployed today will not show a corrected field score for roughly a month.
Why INP Fails Sites That Used to Pass
Browsers run your JavaScript on a single main thread, and that same thread is responsible for painting frames. Any task that occupies it for a long stretch blocks everything else, including the response to the tap that just happened. INP is therefore less a speed metric than a measure of how greedy your JavaScript is with the one thread the user is waiting on.
Three patterns produce almost every failure we see in audits. The first is hydration: a page rendered on the server looks ready in half a second, then the framework downloads, parses, and re-attaches event handlers to the whole tree. During that window the page is visually complete and functionally dead - clicks land in a queue and are answered a second later.
The second is third-party scripts. Tag managers, chat widgets, session recorders, heatmaps, consent banners, and ad scripts each run their own work on the same thread. No single one is the culprit, which is exactly why nobody removes any of them.
The third is expensive event handlers. A click that filters a large list, recalculates a cart, or triggers a synchronous layout read forces the browser to redo layout for the whole document before it can paint. On a mid-range Android phone - which is what most of your traffic is using - that arithmetic runs four to six times slower than on the laptop where it was written and tested.
The Fixes That Move INP, In Order of Payoff
- Break up long tasks. Any task over 50ms is a blocker. Yield back to the browser mid-work with
scheduler.yield()where it is supported, orsetTimeoutwith a zero delay as a fallback. - Paint feedback first, compute second. Show the pressed state, the spinner, or the checkmark, then do the heavy work on the next frame. Perceived response is what the metric records.
- Audit third parties by cost, not by name. Load non-essential tags after interaction, or move the tagging server-side entirely.
- Delete JavaScript. Container queries, native dialogs, popovers, details/summary, and CSS view transitions now replace whole categories of widget with zero main-thread cost.
- Stop hydrating what never changes. Islands, server components, and plain static HTML for static sections cut the largest single INP contributor on framework sites.
LCP and CLS Are Mostly Solved Problems
Compared with INP, the other two are tractable. LCP is usually one of four things: a slow server response, a hero image that is discovered late, render-blocking CSS or fonts, or an image that is simply too large. Preload the hero, set fetchpriority="high" on it, never lazy-load the element above the fold, serve modern formats, and put a CDN in front of the origin. That sequence fixes most sites in an afternoon.
CLS is even simpler and almost always caused by omission. Width and height attributes missing from images, ad or embed slots with no reserved space, web fonts swapping in at a different size, and banners injected above existing content are responsible for nearly all of it. Reserve the space in CSS and the score fixes itself.
Lab Numbers Are Not Your Score
Running a Lighthouse test and screenshotting a green 98 proves very little. Lab tools simulate one visit on one synthetic device and they cannot produce an INP value at all, because there is no human clicking anything. What Google actually uses is field data collected from real Chrome users, aggregated in the Chrome User Experience Report.
Use the lab for diagnosis - it tells you which script is expensive and which image is oversized - and the field for grading. If your site is too small to appear in the public dataset, add a lightweight real-user monitoring script, or use the browser's own performance APIs to report the three metrics back to your analytics. Measuring your own visitors is more accurate than any external estimate, and it is roughly thirty lines of code.
Does Any of This Still Affect Rankings?
Directly, modestly. Google has been consistent that page experience is a tiebreaker rather than a lever: it will not lift weak content above strong content, but between two comparable pages it decides. The commercial argument was always stronger than the ranking argument anyway. Slow interactions cost conversions on the exact pages where conversions happen - checkouts, filters, forms, and booking flows.
What is genuinely new in 2026 is the second audience. AI crawlers and answer engines fetch pages constantly, and they are considerably less patient than a human. Many render little or no JavaScript and abandon slow responses outright. A page whose content only exists after hydration can be invisible to the systems now summarising your industry for buyers, no matter how good it looks in a browser. Fast server-rendered HTML is no longer only a courtesy to visitors on poor connections - it is what determines whether a machine reading the web can see you at all.
Where to Start
Pull your field data first and find which of the three metrics is actually failing, on which template, on mobile. Fix the templates that carry traffic and revenue rather than the homepage everyone stares at. Then take one honest look at the third-party scripts - most sites carry at least one that nobody has used in a year and nobody wants to be the one to delete.
Then wait. The 28-day window means patience is part of the process, and the sites that keep passing are the ones that put a performance budget in the build rather than a cleanup sprint in the calendar.
