“Is my site fast enough for Google?” Google answers with three measurements, the Core Web Vitals. They are collected from real visitors, on their real phones, and describe what they feel: does the page arrive quickly, does it respond when you tap, does it stay in place?
Here is what they measure, the thresholds to aim for, how to read them without being a developer, and what they really weigh in the ranking.
Three measurements, three sensations
- LCP (Largest Contentful Paint): the time it takes to display the largest element visible on the first screen, an image, a block of text, the poster or the first frame of a video. It is the sensation of loading.
- INP (Interaction to Next Paint): the delay between a visitor’s action (a tap, a click, a key press) and the page’s visible reaction, observed over the whole visit. Hovering and scrolling don’t count. INP replaced the old FID measurement in March 2024.
- CLS (Cumulative Layout Shift): layout jumps, when a text suddenly moves down because an image or a banner loaded above it. It is stability.
The thresholds, as Google publishes them:
| Measurement | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 s or less | up to 4 s | more than 4 s |
| INP | 200 ms or less | up to 500 ms | more than 500 ms |
| CLS | 0.1 or less | up to 0.25 | more than 0.25 |
The 75th percentile rule
A threshold isn’t judged on one visit. Google looks at the 75th percentile of visits, separately on mobile and on desktop. In other words: at least three visits out of four must be in the green. A page passes the test if it meets all three thresholds at once, and in Search Console, a group of pages takes the rating of its worst measurement.
Few sites manage it. In July 2025, 48% of sites passed all three thresholds on mobile, against 44% a year earlier. LCP is the hardest: 62% of sites had a good one on phones, against 77% for INP and 81% for CLS (Web Almanac 2025, HTTP Archive).
Measuring them without being a developer
- PageSpeed Insights. Paste your site’s address. The top of the page shows real data from Chrome users over the last 28 days. The bottom shows a lab test: a simulated load, on a fixed device and connection.
- The Core Web Vitals report in Search Console. The same real data, by groups of pages, on mobile and on desktop. Only indexed pages appear there. After a fix, the validation button starts 28 days of monitoring.
- Lighthouse, in Chrome’s developer tools, to test while you change the page. It doesn’t measure INP, lacking a real visitor, and replaces it with an estimate.
A small site often doesn’t have enough visits for Chrome to publish its real data. PageSpeed Insights then falls back on the whole site, or shows only the lab test. Complete it with a try on your own phone, on 4G, in the street.
What speed weighs in Google
Google says it clearly: its ranking systems seek to reward pages that offer a good experience, and they take the Core Web Vitals into account. There is no single “page experience signal”, though.
But Google adds that search always shows the most relevant content, even if the page experience is lacking. Good measurements don’t guarantee the top spot. They matter mostly when many useful pages answer the same question equally well.
Put plainly: a fast page that answers nothing won’t beat a slower page that answers. Content first. Speed breaks ties, and above all, it keeps your visitors.
What most often slows a small site down
Weight. In July 2025, the median homepage weighed more than 2 MB on mobile, and images made up the largest share of bytes (Web Almanac 2025). Search Console’s help gives a much stricter benchmark: under 500 KB for a page and all its resources, and at most 50 resources on mobile. A page with a video background quickly exceeds it; all the more reason for the video to be short, compressed, and for everything else to be light.
LCP. web.dev’s advice for speeding it up:
- the main image is declared directly in the page, not discovered later by a script;
- it is never lazy-loaded: lazy loading is reserved for images lower down;
- it is served at the right size, in a modern format such as WebP or AVIF;
- fonts don’t block text from displaying while they load.
A useful detail for a full-frame first screen: Chrome leaves out of the calculation elements that cover the whole screen, which it treats as a background. The largest element measured may then be your headline. Make it display early, without waiting for a font or a script.
CLS. The classic causes: images and videos without declared dimensions, a fallback font bigger or smaller than the final font, a banner or a widget inserted above the content after the fact.
INP. It suffers when the browser is busy running long scripts at the moment the visitor touches the screen. Every script added, third-party services included, can contribute.
On sites composed in the 29webs studio, the background video is re-encoded and slimmed down, without a sound track, and paired with a poster. If visitors have asked their device for less animation, the video fades away and the poster stays. The details are on the video background page.
In short: aim for display within 2.5 seconds, a reaction within 200 milliseconds and a page that doesn’t jump, for three visits out of four. Measure with PageSpeed Insights and Search Console. And keep Google’s order: relevance first, speed second.
Sources
- Google Search Central, Core Web Vitals and search results (2025)
- Google Search Central, Page experience in search results (2026)
- web.dev, Web Vitals (2024)
- web.dev, INP becomes a Core Web Vital (2024)
- web.dev, Largest Contentful Paint (2025)
- web.dev, Interaction to Next Paint (2025)
- web.dev, Cumulative Layout Shift (2023)
- web.dev, Optimize LCP (2025)
- Google, About PageSpeed Insights (2024)
- Google, Search Console Help: Core Web Vitals report
- HTTP Archive, Web Almanac 2025, Performance chapter (2026)
- HTTP Archive, Web Almanac 2025, Page Weight chapter (2026)