Core Web Vitals and Page Experience
Core Web Vitals is a set of metrics measuring real-world user experience for loading, interactivity and visual stability of a page. Google highly recommends site owners achieve good Core Web Vitals for success with Search. It is often written "an official ranking factor since 2021"; the documentation is more precise and more careful, and how much effort to invest depends on that precision. Below: thresholds, data sources, ways to improve and what Google says outright about the role of page experience in ranking.
The basis is Google's pages on Core Web Vitals and page experience, plus the web.dev guides to the metrics.
Three metrics and thresholds
| Metric | What it measures | Google's guide |
|---|---|---|
| LCP Largest Contentful Paint | loading speed | within the first 2.5 seconds of the page starting to load |
| INP Interaction to Next Paint | responsiveness | less than 200 milliseconds |
| CLS Cumulative Layout Shift | visual stability | less than 0.1 |
The documentation advises striving for these values. How to assess them is explained by web.dev: to hit the targets for most of your users, measure the 75th percentile of page loads, segmented across mobile and desktop devices, and a page passes if it meets the targets for all three metrics. Metrics change: INP became a stable Core Web Vital in 2024, replacing FID. So FID is not in the current list.
What Google says about ranking
This is where misconceptions are most common. From the page experience page:
- There is no single page experience signal: the core ranking systems look at a variety of signals that align with overall page experience;
- Core Web Vitals are used by the ranking systems, but good results in reports do not guarantee top positions, and chasing a perfect score just for SEO is not the best use of time;
- Other page experience aspects beyond Core Web Vitals don't directly help a site rank higher, though they make a site more satisfying to use and align with what the systems seek to reward;
- Google always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries there is lots of helpful content, and then a great page experience can contribute to success.
So "HTTPS is mandatory for ranking" and "mobile-friendliness as a ranking signal" are not what the documentation says. In it these are self-assessment questions: good Core Web Vitals, secure serving, content that displays well on mobile, no excessive ads and intrusive interstitials, and a clear distinction of the main content from the rest. The systems evaluate content mainly on a page-specific basis, but there are some site-wide assessments.
Data: field and lab
Core Web Vitals are first and foremost field metrics. Field data is collected by the Chrome User Experience Report, which powers PageSpeed Insights, Chrome DevTools and the Core Web Vitals report in Search Console. Lab measurement is for development: it is best for testing features before release and catching regressions. It does not replace field data, because test conditions differ from real users. Our page analyzer shows lab LCP and CLS and, where available, field LCP, INP and CLS for the page and for the whole site from PageSpeed Insights.
How to improve
- LCP. Never lazy-load your LCP image: that always creates unnecessary delay and hurts LCP. Priority is signalled with the fetchpriority hint. "Lazy loading" is often advised as a way to speed up LCP, and that is wrong for the main image. On images, see the lesson on image SEO;
- CLS. Always include width and height attributes on images and video, or reserve the space with CSS aspect-ratio;
- INP. One common cause is long JavaScript tasks. Yielding to the main thread helps: break up long tasks and yield right after an event callback that updates the interface. More in web.dev's guide to optimizing INP; on scripts, the lesson on JavaScript and SEO.
What is not in the documentation
- An "official ranking factor since 2021": Google says Core Web Vitals are used by the ranking systems alongside other aspects of experience;
- HTTPS and mobile-friendliness as direct "ranking signals";
- "Lazy loading" as a way to speed up LCP;
- Figures such as "bounce rate fell 18%" as consequences of optimization: that is one site's data.
How to check a site
- Open the Core Web Vitals report in Search Console and find groups of pages with poor values.
- For important pages get a report in the page analyzer: field data and lab bottlenecks.
- Assess mobile and desktop values separately, as web.dev advises.
- Find templates repeated on many pages: fixing a template improves all its pages. A page list comes from the crawler.
- After changes wait for field data to accumulate: it is computed from real users, not immediately.
Checklist
- LCP within 2.5 seconds, INP under 200 ms, CLS under 0.1 at the 75th percentile.
- The main image is not lazy-loaded; images and video have dimensions.
- Long JavaScript tasks are broken up.
- I look at field data, not only lab data.
- Mobile and desktop data are assessed separately.
- Page experience is judged as a whole, not by one metric.
Mistakes
- Treating Core Web Vitals as the only factor and chasing a perfect score for SEO.
- Lazy-loading the main image.
- Assessing only lab data.
- Not specifying image dimensions.
- Optimizing FID instead of INP.
What comes next
The last lesson of the module is site migrations: how to keep results when addresses change. Data for rich results is in the lesson on structured data.