No, Google Did Not Lower the LCP Threshold to 2 Seconds

No, Google has not lowered the "good" Largest Contentful Paint threshold to 2 seconds. As of June 2026, every official Google source still defines a good LCP as 2.5 seconds or less. The "new 2.0-second threshold" doing the rounds is not a Google announcement. It is a claim that several SEO blogs have confidently repeated into existence.

If you have read otherwise and quietly panicked about your CrUX data, you can stop. Here is what Google actually says, where the rumour came from, and what genuinely is worth your attention on Core Web Vitals this year.

What the rumour claims

The story goes that a "March 2026 core update" lowered the good LCP threshold from 2.5 seconds to 2.0 seconds, pushing any page between 2.0s and 2.5s from passing to failing overnight, and that INP was "elevated to equal weight" at the same time. It usually arrives with very specific numbers attached: average ranking drops of two to four positions, exact percentages, that sort of thing.

The specifics are the tell. Real Google threshold changes are announced loudly, on web.dev and the Search Central blog, with a dated post and a migration note. This one has no such source. The blogs making the claim cite each other, never Google, because Google never said it.

What Google actually says

The thresholds have not moved. Three official, current Google sources all state the same numbers:

• web.dev's LCP guide (last updated September 2025): "sites should strive to have Largest Contentful Paint of 2.5 seconds or less."
• Google Search Central's Core Web Vitals doc (last updated December 2025): LCP should occur "within the first 2.5 seconds of the page starting to load."
• web.dev's article on how the thresholds were defined: it explicitly tested a 2-second threshold and rejected it, on the grounds that it "is not consistently achievable" even for well-optimised sites.

That last point is the one that kills the rumour outright. Google did not just decline to lower the threshold to 2 seconds; it studied that exact number and concluded it was too strict to be fair. A threshold that aggressive would tip a large share of the web into the red without telling anyone anything useful, which is the opposite of what a ranking signal is for.

For the record, the official thresholds in 2026 are unchanged:

Metric	Good	Needs improvement	Poor
LCP	≤ 2.5s	2.5s to 4.0s	> 4.0s
INP	≤ 200ms	200ms to 500ms	> 500ms
CLS	≤ 0.1	0.1 to 0.25	> 0.25

All three are measured at the 75th percentile of real visits.

Where the 2-second number probably came from

The likely culprit is a mix-up between LCP's two sub-parts and the metric as a whole. Google's guidance does recommend that the largest element start rendering well before the 2.5-second mark, and breakdowns of LCP often suggest keeping the earlier phases (time to first byte, resource load) inside roughly the first 2 seconds so the full metric lands under 2.5s. Somewhere in the retelling, an internal budget for one phase got reported as a new threshold for the whole metric.

Add a content pipeline that rewards confident, freshly-dated posts about "2026 changes", and a plausible-sounding number turns into received wisdom in a few weeks. It is a neat illustration of the thing I keep telling clients: verify Core Web Vitals claims against web.dev and Search Central, not against the tenth blog to repeat them.

What is actually true about Core Web Vitals in 2026

The thresholds are stable, but two things genuinely deserve your attention.

INP is still the metric most sites fail. It replaced First Input Delay in March 2024, and roughly 43 percent of sites still miss the 200ms mark. INP has been a full Core Web Vital, weighted alongside LCP and CLS, ever since. That is not a 2026 change either, but it is the real story the rumour was clumsily reaching for. If you want the practical version, see how to fix INP.

Field data shifts under you even when thresholds do not. Your scores come from the Chrome User Experience Report, a rolling 28-day average of real visitors. A new ad script, a heavier hero image, or a traffic shift towards slower devices can move you from passing to failing without anyone changing a threshold or, for that matter, telling you. That is the genuine version of "you started failing without changing a line of code", and it is worth more of your worry than any imagined rule change.

How to know if you are actually passing

Check the source Google ranks on, which is field data, not a one-off lab score. Open the Core Web Vitals report in Google Search Console; it reads from CrUX and groups your URLs into good, needs-improvement, and poor against the real thresholds above. A green Lighthouse run on your laptop tells you almost nothing here, because Lighthouse is lab data on one machine and cannot measure INP at all.

If GSC shows LCP in the amber or red band, the fixes are well understood: get the LCP element painting sooner with a faster server response, a preloaded hero image, and fewer render-blocking resources. The threshold you are aiming at is 2.5 seconds. It was 2.5 seconds last year, and despite what you may have read, it is 2.5 seconds now.

The takeaway

Believe the threshold change when web.dev or the Search Central blog publishes it, and not a moment before. Until then, a good LCP is 2.5 seconds, a good INP is 200 milliseconds, and a good CLS is 0.1. Spend the energy you were about to waste re-checking a phantom rule on the metric you probably are failing, which is INP.

If you would rather not work out which of those bands your site actually sits in, that is exactly the sort of thing an audit settles in an afternoon, against real field data, with the numbers traced to a cause.