Core Web Vitals thresholds did not change in 2026. Despite a steady supply of articles announcing that Google changed the rules again, the primary documentation still lists the same three metrics at the same numbers, and the thresholds page was last updated in May 2025. What has changed is the business case. The strongest evidence for fixing INP is not ranking position, which Google has always described as a minor signal. It is conversion rate, and the gap is larger than most people expect.

The actual current thresholds

Straight from Google’s own documentation, with the dates those pages were last revised.

INP is the one most sites fail. It measures responsiveness: the delay between a user interacting with your page and the page visibly responding. Assessment uses the 75th percentile of page loads, measured separately for mobile and desktop, and a page passes only if all three metrics hit their target.

One technical detail worth knowing, because it trips people up. The web-vitals JavaScript library takes the 98th percentile of interactions within a single page view to produce that page’s INP value. The 75th percentile then applies across page views. Two different percentiles doing two different jobs.

About the articles saying Google changed the rules

There is a genre of content claiming a 2026 Core Web Vitals update. It is worth understanding what is actually in it, because you will encounter it while researching this.

One widely circulated example describes itself as an analyst synthesis rather than a news report. Its own summary states that the 2026 update did not move the three published thresholds. It cites no Google announcement, no web.dev page, no Chrome blog post and no changelog entry. Its pass-rate statistics carry no source, and it contradicts itself on the LCP failure rate, giving 22% in one section and 28% in another. It also claims that sites with good Core Web Vitals show a three to four times higher AI citation rate, then labels that observation not a controlled study and directional only.

None of which means nothing has changed. Measurement methodology and tooling do evolve, and CrUX coverage expands. But Google’s documented policy is that stable Core Web Vitals change no more than once a year, with prior notice, and that any change appears in both the metric documentation and its changelog.

So the test is simple. If an article announces a Core Web Vitals change and cannot point you at a Google URL, it has not found one.

What INP actually costs: the conversion case

Here the evidence is more interesting, with one significant caveat.

Contentsquare analysed 997 customer sites over three months and compared business outcomes against INP buckets.

On desktop the gap is striking. On mobile it almost disappears, which Contentsquare attributes to lower user expectations on phones.

They also measured frustration signals, defined as rage clicks and repeated interactions with the same element. Users on poor-INP pages experienced frustration 38% of the time against 33% on good-INP pages, rising to 41% against 35% in retail.

Three caveats, and they matter. The data is from mid-2023, before INP became an official Core Web Vital, which makes it three years old. Contentsquare sells digital experience monitoring, so there is a commercial interest. And to their credit they state the obvious limitation themselves: correlation is not causation. They also note that bounce could run the other way, since users who bounce interact less and therefore generate worse INP readings.

Treat the direction as reliable and the magnitudes as indicative.

The ranking question, answered honestly

Core Web Vitals are a confirmed page experience signal in Google Search. They have also always been described as a minor one, and nothing in the current documentation elevates them.

The practical reality is that a fast site with thin content does not outrank a slow site with excellent content. Speed acts closer to a tiebreaker between comparable pages than to a lever you pull for rankings.

Which is why the conversion data above is the argument worth making internally. A 25% conversion difference in retail is a revenue number your finance director will understand. A possible tiebreaker advantage in search is not.

How to actually fix INP

INP is a JavaScript problem in almost every case. The page has received the interaction and the main thread is too busy to respond.

Audit your third-party scripts first. Chat widgets, heatmaps, consent managers, review widgets, analytics and tag managers all compete for the main thread. This is usually where the worst offenders live, and removing one unused tool often beats hours of optimisation.

Break up long tasks. Any script execution blocking the main thread for more than 50 milliseconds delays every interaction behind it. Splitting work into smaller chunks and yielding back to the browser between them lets queued interactions through.

Defer anything not needed for the first interaction. Load it after the page becomes interactive rather than before.

Reduce your DOM size. Very large DOMs make every style recalculation and layout pass more expensive, which inflates INP on pages that otherwise look fine.

Check your event handlers. Handlers doing heavy synchronous work, or firing on every scroll or input event without throttling, are a common cause.

Measure with field data, not lab data. This is the one people get wrong. Lighthouse cannot measure INP properly because INP depends on real user interactions. Use Search Console’s Core Web Vitals report, the CrUX data in PageSpeed Insights, or real user monitoring. A perfect Lighthouse score tells you very little about your INP.

Where to start

Pull your Search Console Core Web Vitals report and look at the mobile INP figure at the 75th percentile. Mobile is where most sites fail, and the Contentsquare benchmark put average mobile INP in the needs improvement band bordering on poor.

If you are failing, start with the third-party script audit. It is the cheapest intervention with the largest typical effect, and it frequently reveals tools nobody remembers installing.

Want to know what your site actually scores?

We will pull your field data, identify which scripts are costing you INP, and give you a prioritised fix list with the likely conversion impact rather than just a score.

No charge, and the findings are yours either way.

Frequently Asked Questions

Did Core Web Vitals thresholds change in 2026?

No. Google’s documentation still lists the same three metrics at the same values — LCP at 2,500ms, INP at 200ms, CLS at 0.1 — and the thresholds page was last revised in May 2025. Google’s stated policy is that stable Core Web Vitals change no more than once a year, with prior notice in both the documentation and the changelog.

What is a good INP score?

200 milliseconds or less, measured at the 75th percentile of page loads and assessed separately for mobile and desktop. Above 500 milliseconds is classed as poor. A page passes Core Web Vitals only if LCP, INP and CLS all meet their targets at the 75th percentile.

How much does INP affect conversion rate?

Analysis of 997 sites found retail conversion averaging 2.5% with good INP against 2.0% with poor or needs-improvement INP — a 25% difference. On desktop the gap was 4.2% against 2.9%. On mobile it narrowed to 1.9% against 1.7%. That data is from 2023 and vendor-published, so treat the direction as reliable and the magnitudes as indicative.

Do Core Web Vitals affect Google rankings?

Yes, but weakly. They are a confirmed page experience signal and have consistently been described as a minor one. A fast page with thin content will not outrank a slow page with excellent content. Speed functions closer to a tiebreaker between comparable pages than a ranking lever, which is why the conversion case is the stronger argument.

Why can’t Lighthouse measure my INP?

Because INP depends on real user interactions, and Lighthouse runs a simulated load with no user interacting. You need field data: Search Console’s Core Web Vitals report, the CrUX data shown in PageSpeed Insights, or real user monitoring. A perfect Lighthouse score tells you very little about your actual INP.

What is the fastest way to improve INP?

Audit your third-party scripts. Chat widgets, heatmaps, consent managers, review tools and tag managers all compete for the main thread, and removing one unused tool often achieves more than hours of code optimisation. After that: break up tasks longer than 50ms, defer anything not needed for the first interaction, and reduce DOM size.