The Core Web Vitals thresholds did not change in 2026

Anyone searching for Core Web Vitals in the summer of 2026 runs into an announcement fairly quickly. Google supposedly assesses the values site-wide since the March core update, every page on a domain supposedly feeds into one combined value, and a single slow product page supposedly drags the whole domain down. None of that appears in any Google source.

I went through the primary sources on 27 July 2026. Not the summaries, but the documentation pages themselves, the Chromium changelogs, the Search Status Dashboard and the CrUX release notes. What follows is what is actually there, what is not, and what really did change in 2026.

What the Google sources say

Three metrics, three values, each measured at the 75th percentile of page views and split by mobile and desktop.

Largest Contentful Paint counts as good at 2.5 seconds or less. The page web.dev/articles/lcp carries 4 September 2025 as its last update.

Interaction to Next Paint counts as good at 200 milliseconds or less, as needing improvement up to 500 milliseconds and as poor above that. The page was last updated on 2 September 2025.

Cumulative Layout Shift counts as good at 0.1 or less and as poor from 0.25 upwards. That page was last touched on 12 April 2023.

The overview page web.dev/articles/vitals, last updated 31 October 2024, names exactly these three metrics and knows no combined overall score.

Then there are the changelogs, which are worth more than any documentation page for questions like this, because they record every measurement change against a version. The Chromium changelog for LCP has Chrome 140 and Chrome 143 as its most recent entries, both from 2025 and both about a text timestamp reported too early. The changelog for INP ends at Chrome 133 from February 2025. Neither file contains a single entry from 2026.

One addendum on the original question about a lowered LCP threshold, because it belongs to the matter. I checked several German-language results on the topic, including ones written specifically to serve that search term. All of them correctly state 2.5 seconds, and one even explicitly clarifies that the values have been unchanged since the INP rollout in March 2024. The lowering is therefore a widespread search query rather than a widespread claim. The claim that actually circulates is a different one.

Photo: codzilla_swiss / Unsplash

Why 2.5 seconds of all values

Google described how the thresholds are set in a dedicated methodology document, written by Bryan McQuade and Barry Pollard and last updated on 7 May 2025. Three criteria decide it. The value has to represent a high-quality user experience, it has to be achievable, and it has to be the same across device classes. Achievable means concretely that at least 10 per cent of origins must be able to reach the good value at all.

The documented intermediate step is the interesting part. The values 1.5 seconds and 2 seconds were examined as an LCP threshold and rejected, because even well optimised pages could not reach them consistently at the 75th percentile. 2.5 seconds was the lowest value that cleared the achievability hurdle.

That is why a quiet lowering would be implausible. Google would have to re-argue its own 10 per cent criterion and document the shift. Neither has happened.

Claim 1: site-wide scoring since March 2026

The load-bearing claim says that since the March 2026 core update Google no longer assesses individual pages but the whole domain, and that poor subpages pull the rest down with them.

The counter-check in the official Search Status Dashboard. Five ranking updates are recorded there for 2026: the Discover update of 5 February 2026 running for 21 days and 17 hours, the spam update of 24 March 2026 with 19 hours and 30 minutes, the core update of 27 March 2026 with 12 days and 4 hours, the core update of 21 May 2026 with 11 days and 21 hours, and the spam update of 24 June 2026 with 2 days and 1 hour. None of them concerns Core Web Vitals or page experience. The most recent page-experience-related update in the official history is the desktop update of 22 February 2022.

Google’s page experience document in Search Central was last updated on 10 December 2025. It deliberately names no concrete numeric thresholds and stresses that there is no single signal. The secondary source I checked does link to Search Central, web.dev, the status dashboard and CrUX, but quotes not one sentence from any of them.

The reverse conclusion, that Core Web Vitals are a purely page-level signal, is not in there either. The document says the core ranking systems generally evaluate content on a page-specific basis, including for aspects related to page experience, but that there are also some site-wide assessments. That is a statement about the ranking systems as a whole and not one about Core Web Vitals in particular. As evidence it works neither for a domain signal nor for a cleanly delimited page-level signal. Only the one point is demonstrable. There is no Google source for a switch to site-wide scoring in March 2026, and the March update was described as a regular core update.

Photo: firmbee / Unsplash

Claim 2: tightened INP measurement methodology

One English-language source traces the drop in pass rates back to a tightened INP measurement in 2026, plus expanded CrUX coverage of soft navigations and a more prominent TTFB in PageSpeed Insights. As evidence it names, in blanket terms, documentation updates through April 2026 and the Chrome team’s public writing, with no URL, no date and no quote.

The INP changelog has no entry from 2026. Google itself explains the decline differently, more on that shortly. This claim remains unsupported.

Claim 3: the combined overall score

There is no aggregated Core Web Vitals score. The overview page knows three metrics with three thresholds, and nothing more.

What does exist, and what is easily confused with it, is the CrUX figure for “good Core Web Vitals overall”. That is the share of origins passing all three metrics, so a statistic about the state of the web and not an assessment of an individual website.

The new Lighthouse category “Agentic Browsing” is not a score either. It requires Chrome 150 or newer and is, according to its documentation as of 5 May 2026, explicitly informative and unbenchmarked. It checks the registration of WebMCP tools, the quality of the accessibility tree, visual stability via CLS and the discoverability of an llms.txt. No weighted number from 0 to 100 comes out of it.

The figures that really did fall

The May 2026 CrUX dataset, published on 9 June 2026, reports 68.6 per cent good LCP (down 0.5), 81.3 per cent good CLS, 86.6 per cent good INP (down 0.6) and 55.9 per cent good Core Web Vitals overall (down 0.8). The June dataset of 14 July 2026 sits at 67.7 per cent LCP (down 1.2), 81.4 per cent CLS (up 0.1), 85.9 per cent INP (down 0.8) and 55.3 per cent overall (down 1.2).

Google’s own reading of this names a regression above all on Android and classifies the further year-on-year declines as seasonal. On the cause it says verbatim that it has theories but “nothing definitive to share yet”. No change to metrics, thresholds, dimensions or measurement methodology is announced in the 2026 release notes.

That also explains how the confusion can arise. CrUX has always delivered two levels, origin level and page level. Page-level data additionally requires public discoverability, meaning no non-200 status and no noindex, plus a minimum number of visitors that Google does not publish. Experiences that only meet the origin criteria still land in the origin dataset. Anyone who sees only the origin level in a tool, because the individual page does not clear the page-level hurdle, quickly takes that for a new site-wide assessment. The methodology documentation on this has been online unchanged since 20 June 2024.

Photo: lukechesser / Unsplash

Timeline 2026

Lighthouse 13.0.0 still appeared in 2025, on 10 October, switching the performance audits to DevTools insights, requiring Node 22.19 as a minimum and removing seven audits without replacement. Explicitly with no change to performance scoring, because the score rests on metrics and not on audits.

In 2026 the changelog lists 13.0.2 on 6 February, 13.0.3 on 11 February, 13.1.0 on 3 April with a baseline compatibility audit, 13.2.0 on 30 April with three WebMCP audits, 13.3.0 on 7 May with Agentic Browsing in the default configuration, 13.4.0 on 9 June with Agentic Browsing in the PageSpeed Insights API viewer, and 13.4.1 on 20 July.

Alongside that, the Chrome blog post on the “agent-ready toolkit” of 22 June 2026 with three building blocks: the Lighthouse category from Chrome M150, the WebMCP standard and Chrome DevTools for Agents.

The final origin trial for the soft navigations API was announced on 20 April 2026 and runs from Chrome 147 to Chrome 149. What is being tested are the SoftNavigationEntry and InteractionContentfulPaint entries as well as navigationId identifiers. A soft navigation is defined through three criteria: it is triggered by a user action, it leads to a visible URL change, and the interaction leads to a visible paint. Availability without a flag is planned from Chrome 151, whose stable date is set for 28 July 2026.

Important for context: Google explicitly writes about the origin trial that it serves to evaluate the API itself and not the question of how the data is used in CrUX or in tools. That is to be decided only after launch.

// Observe soft navigations from Chrome 151 without a flag.
// Whether and how these values ever feed into CrUX is open.
new PerformanceObserver(function (list) {
  for (const entry of list.getEntries()) {
    console.log('soft navigation', entry.name, entry.startTime, entry.navigationId);
  }
}).observe({ type: 'soft-navigation', buffered: true });

new PerformanceObserver(function (list) {
  for (const entry of list.getEntries()) {
    console.log('interaction contentful paint', entry.startTime, entry.navigationId);
  }
}).observe({ type: 'interaction-contentful-paint', buffered: true });

Anyone running an SPA or View Transitions finally gets measured values for navigations that used to be completely invisible. None of it is ranking-relevant for now.

The lab value does not measure, it calculates

The real reason threshold debates achieve so little lies elsewhere. PageSpeed Insights and Lighthouse do not measure by default, they simulate. The page is loaded unthrottled, after which the Lantern model extrapolates the metrics onto a Moto G Power, onto slow 4G at 1.6 Mbps and quadruple CPU throttling.

During the V3 optimisation of emit-solution.com on 9 July 2026 the PageSpeed score rose from 70 to somewhere between 92 and 96, and the simulated LCP fell from 6.7 seconds to 2.4 seconds. The largest hidden lever was 42 KB of render-blocking CSS, which on its own cost around 3.5 seconds of simulated LCP. The reason lies in the model. Lantern counts every request that starts before the observed LCP as an LCP dependency, regardless of whether the paint needs it at all.

Then there is the variance. Identical code returned 52 points in one PageSpeed Insights run and 95 in another, because the test runners share the CPU. A single run is no basis for anything, three runs and the median are. More on that in the guide to deferring loading until after the LCP.

For ranking, CrUX is what counts anyway, meaning field data from real users. The lab value is diagnosis. If the observed paint is fast and the audience is on a decent connection, the field values are often better than the simulation suggests.

Photo: zetong / Unsplash

Checking reports like this yourself

Four sources are enough for almost any claim of this kind. The Chromium changelog under docs/speed/metrics_changelog answers every question about the measurement methodology of a metric. The Search Status Dashboard lists every ranking update with start, end and duration. The CrUX release notes document every change to the dataset. And the web.dev articles carry their update date at the bottom, which immediately exposes a supposedly new threshold on a page that has been unchanged since 2023.

And if a number in your own report looks implausible, looking into the raw audit helps more than looking at the results tile.

npx lighthouse <url> --form-factor=mobile --screenEmulation.mobile \
  --throttling-method=simulate --only-categories=performance \
  --output=json --output-path=audit.json --chrome-flags="--headless=new"

// What to look at in the JSON:
// audits.metrics.details.items[0]             -> observed vs. simulated
// audits['largest-contentful-paint-element']  -> LCP element plus phases
// audits['network-requests']                  -> filtered on
//                                                networkRequestTime < observedLCP
//                                                gives the real LCP chain
// audits['screenshot-thumbnails']             -> filmstrip as base64

If you have a Core Web Vitals report on your desk right now and want to know whether your site would be affected, look at your CrUX values rather than at the lab score. I am happy to help work out which number carries which lever on your site. Just get in touch with the URL.