Core Web Vitals thresholds did not change

Nobody moved the Core Web Vitals goalposts. LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, all judged at the 75th percentile of a rolling 28-day window. If you have read a post claiming Google tightened LCP to 2.0 seconds this year, you have read machine-written filler. Google's own documentation still says 2.5.

What did change is more interesting, and it will move your reported numbers without anyone touching your site.

Soft navigations landed in Chrome 151

Chrome began rolling 151 to stable on 28 July 2026, and it shipped the soft-navigation and interaction-contentful-paint entry types unflagged, out of origin trial.

Here is what that means in plain terms. Until now, a single-page app got one set of vitals: whatever happened on the first page load. Every route change after that was invisible to the metrics, so a site could load one heavy shell, score beautifully, and deliver a slow experience for the next twenty minutes of the session.

Chrome now detects a route change inside the app and starts a fresh metric lifecycle for it. Three conditions have to be met: the change was started by a user action, the URL visibly changed, and something visibly painted. Get all three and LCP, INP and CLS are attributed to that route instead of being dumped on the initial load. TTFB is reported as zero for soft navigations, which is correct, because there was no new document request.

One detail worth knowing if you are wiring this up: the static attribute for the largest interaction contentful paint was replaced by a method call. Code written against the origin trial will break.

Google has not yet decided how its field dataset will report soft navigations. So field data is coming, but the shape of it is not settled.

The trap nobody is flagging

The web-vitals library shipped version 6 on 21 July 2026 with native soft-navigation support.

If your site already runs a virtual pageview shim, and most analytics setups on single-page apps do, you now have two systems trying to define the same thing. You will double-count route changes, and INP attribution will cross route boundaries differently in each system.

Worse for your Monday morning: your reported percentiles can get noticeably worse without a single regression. Sessions that were previously invisible are now being measured. The deep in-app routes that were always slow are finally showing up in the numbers.

Do not let that land as a surprise in a board pack.

Run the old and new measurement in parallel for at least one full 28-day cycle before you cut over. Stamp both the browser version and the web-vitals library version on every beacon you send. Without those two fields, no historical comparison you make after this survives scrutiny.

Your own data and Google's are about to diverge, and that is correct

Cross-browser measurement quietly arrived.

Firefox 144, released October 2025, added INP through a per-interaction identifier. It has supported LCP since January 2024. Safari 26.2, released 12 December 2025, shipped LCP and the Event Timing API that INP is built on, though Safari's INP implementation still has bugs and sometimes reports values that are obviously wrong. Firefox also picked up the Scheduler API, including the yield method, in August 2025. Neither browser has announced plans for CLS.

Google's field dataset is Chrome-only and always will be. Safari is more than half of US mobile traffic, and the Australian picture is similar or more iPhone-heavy.

So your real-user monitoring and Google's report will drift apart, and the drift is not an error in either one. Google grades you on Chrome. Your customers are not all on Chrome. Anyone presenting a single blended vitals number without naming the browser mix is presenting a number that means nothing.

Dataset changes you may have missed

The Effective Connection Type dimension was retired from BigQuery and replaced by Round Trip Time. A 75th percentile and histograms are now available, along with LCP image subparts and LCP resource type in the API. That last one is genuinely useful: it tells you whether your LCP element is an image, and which part of the load is eating the time, without you having to reproduce the problem locally.

The dashboard built on the Looker Studio connector was deprecated at the end of November 2025. October 2025 was the last dataset it received. If your monthly report still pulls from it, it has been showing you a frozen picture for eight months.

And on INP: Chrome's changelog has no 2026 entries at all. The last substantive change was in Chrome 133, February 2025. Any claim that Google tightened INP methodology in 2026 is invented.

What this is actually worth commercially

Be honest about the ranking argument. Core Web Vitals are a small ranking factor and always have been. A site that goes from failing to passing rarely sees a rankings jump it can isolate from everything else it changed.

The commercial case is conversion and cost, not position. Interaction delay on a form, layout shift that moves a button under a thumb mid-tap, a hero image that lands two seconds late on a paid landing page you are paying for by the click. Those cost money you can count.

Which is why soft navigations matter more than the ranking conversation ever did. On a multi-step quote form, a booking flow, or a product configurator, every step after the first was previously unmeasured. That is exactly where the drop-offs live.

Instrument the routes you were blind to, then decide what to fix.