The three measures and their pass marks
The web.dev site, run by Google, gives these targets. We read it on 9 October 2026.
- LCP (Largest Contentful Paint): loading. It is the time until the largest image, text block or video in view is drawn. Good is 2.5 seconds or less. Poor is above 4 seconds.
- INP (Interaction to Next Paint): responsiveness to clicks, taps and key presses during the visit. Good is 200 milliseconds or less. Poor is above 500 milliseconds. INP replaced an older measure called First Input Delay.
- CLS (Cumulative Layout Shift): visual stability. It scores unexpected layout shifts. Good is 0.1 or less. Poor is above 0.25.
A value between good and poor is shown as needs improvement.
What the 75th percentile means
web.dev says to judge a page at the 75th percentile of page loads, with mobile and desktop counted separately. In plain words, at least 75 out of every 100 visits should meet the good mark.
A made-up example
A furniture shop's product page is opened 100 times on mobile. On 80 visits the main photo appears within 2.5 seconds. On 20 visits it takes longer. The page passes LCP, because more than 75 visits are fast enough.
If only 60 visits were fast enough, the page would fail LCP, even though most visits were fine. A mark at the 75th percentile means that most visitors, not just half, get a good experience.
Where the numbers come from
web.dev calls Core Web Vitals field metrics first and foremost. Field data comes from real visitors. The Core Web Vitals report in Google Search Console uses the Chrome User Experience Report, which gathers anonymous timings from real users. Search Console groups similar pages, and a group takes its slowest status. Google also says a group with too little data is left out of the report.
Do they affect rankings?
Google's page on Core Web Vitals does not call them a direct ranking factor, and it does not say how much weight they carry. It says it highly recommends good Core Web Vitals for success with Search. It also says they match what its core ranking systems seek to reward. We therefore treat them as part of a good visit, and not as a trick.
Common mistakes
- Testing once on your own fast phone and calling it done. The report uses real visitors on many devices.
- Fixing only the home page. The report looks at groups of pages, so other pages can still fail.
- Not checking again after big changes, such as a new design or a new chat widget.
- Treating a pass as the end goal. A fast page that does not help the visitor still gets no enquiries.
Related terms
- Technical SEO (search engine optimisation): the setup work that lets search engines read your site.
- Bounce rate: the share of visits that leave after one page.
- Conversion rate: the share of visitors who buy, call or fill a form.
- Dwell time: how long a visitor stays before going back to the results.
- Indexing: when a search engine stores a page so it can show it in results.
For fixes, read our Core Web Vitals and site speed guide. If you want help, see our website maintenance service.
Sources
- web.dev, "Web Vitals" (web.dev/articles/vitals), last updated 31 October 2024, read 9 October 2026.
- web.dev, "Largest Contentful Paint" (web.dev/articles/lcp), "Interaction to Next Paint" (web.dev/articles/inp) and "Cumulative Layout Shift" (web.dev/articles/cls), read 9 October 2026.
- Google Search Console Help, Core Web Vitals report (support.google.com/webmasters/answer/9205520), read 9 October 2026.
- Google Search Central, "Understanding Core Web Vitals and Google search results" (developers.google.com/search/docs/appearance/core-web-vitals), last updated 10 December 2025, read 9 October 2026.
