The Core Web Vitals thresholds have not moved. LCP is still 2.5 seconds, INP is still 200 milliseconds, CLS is still 0.1, and that is what Google's own documentation says on 14 August 2026.
Worth stating plainly because a claim has been circulating for months, in English and in Persian, that Google tightened the "good" LCP threshold from 2.5 seconds to 2. No page in Google's documentation says that.
The numbers currently published
| Metric | "Good" threshold | What it measures |
|---|---|---|
| LCP | 2.5 seconds or less | time until the largest element renders |
| INP | 200 milliseconds or less | delay in responding to user interaction |
| CLS | 0.1 or less | unexpected layout movement |
The dedicated LCP page on web.dev is unambiguous: sites should strive for a Largest Contentful Paint of 2.5 seconds or less. That page was last updated on 4 September 2025 and has not changed since.
What Google says about changing a threshold
One sentence on the main Web Vitals page settles the argument. Developers should expect the definitions and thresholds of the Core Web Vitals to be stable, with updates arriving on prior notice and a predictable annual cadence. Google adds that changes are documented in a public changelog.
Which means you would hear it from Google before you heard it from an article with no sources. No such announcement has been made.
Why we still build to under two seconds
Now our own position, which differs from the rumour because the reasoning differs.
On speed work our internal target is under two seconds. Not because the line moved, but because 2.5 seconds is not the number your testing tool shows you on a laptop. The assessment runs at the 75th percentile of real visitors, split between mobile and desktop. Your slowest quarter of users decides whether you pass.
On mobile, on a connection that is not always steady, the gap between a lab figure and the 75th percentile is not small. Score 2.4 seconds in a test and you will quite likely fail on field data.
Aiming at two seconds is a safety margin, not a new standard. If somebody sold you that margin as Google's new rule, they were selling you the thing we just described as a margin.
Where the seconds usually go
The prerequisite is usually neither content nor plugins. It is server response time. We took that relationship apart in what hosting does to your Core Web Vitals numbers, and if the three metrics themselves are new to you, a plain explanation of the three metrics and how they are measured is a better starting point than this news is.
And where speed is not your problem at all
This is the section a company selling speed optimisation does not usually write.
If your LCP is 2.4 seconds and your traffic is flat, the threshold is not what ails you. Getting it to 1.9 buys a green tick in a tool and close to no ranking. Core Web Vitals is a page experience signal and its weight is small next to whether the content matches what the searcher wanted.
Speed earns its budget when the number is genuinely bad, north of four seconds say, or when conversion rather than ranking is the goal. There you see the effect in sales, not in a ranking report.
If traffic is down and you are unsure which problem you have, the right order for diagnosing a drop keeps you from spending on the wrong one, and the wider picture of what SEO work involves shows where speed sits on that list.
If the number really is bad and you want to know how much of it is fixable, a site speed review built on field data starts at that 75th percentile rather than at a screenshot.
Sources
- Web Vitals, Google's reference page for the thresholds, the 75th percentile and the change policy
- Largest Contentful Paint documentation for the 2.5 second figure
Both checked on 14 August 2026.
Comments & Questions
Have a question about this article? Ask, we'll answer.
No comments yet; be the first.