What are the "good" Core Web Vitals thresholds?
Google groups each metric into good, needs improvement and poor. To pass, a page needs a good LCP, INP and CLS at the 75th percentile of visits, measured separately for mobile and desktop. Because Google uses mobile-first indexing, the mobile figures usually matter most for UK businesses.
If your site sits in "needs improvement" or "poor", our website speed optimisation service finds which metric is failing and why, then fixes it at template level.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main content (usually a hero image or headline) appears | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s |
| Interaction to Next Paint (INP) | How quickly the page responds visually to taps, clicks and key presses | ≤ 200 ms | 200–500 ms | > 500 ms |
| Cumulative Layout Shift (CLS) | How much the layout jumps around unexpectedly while the page is used | ≤ 0.1 | 0.1–0.25 | > 0.25 |
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Older guides that mention FID are out of date.
What does Largest Contentful Paint (LCP) measure?
LCP measures how long it takes for the largest visible element in the first screen, typically a hero image, video poster or main heading, to render after the visitor starts loading the page. It is the best single proxy for "has this page loaded yet?" from the visitor's point of view.
Common causes of a slow LCP are a slow server response, a large uncompressed hero image, render-blocking CSS and JavaScript, web fonts that delay text, and hero images that are lazy-loaded when they should load first. Fixes usually involve better hosting or caching, properly sized images in modern formats such as WebP or AVIF, and telling the browser to prioritise the hero image.
What does Interaction to Next Paint (INP) measure?
INP measures how quickly a page responds to user input across the whole visit. It records the delay between a click, tap or key press and the next frame the browser paints, then reports one of the slowest interactions. A high INP feels like a sluggish, unresponsive button or menu.
Poor INP is almost always a JavaScript problem: long tasks blocking the main thread, heavy third-party scripts such as chat widgets, tag managers and ad scripts, and large page builders that run a lot of code on every interaction. Fixes include removing scripts you do not need, deferring the rest, and breaking long tasks into smaller pieces.
What does Cumulative Layout Shift (CLS) measure?
CLS measures how much visible content moves unexpectedly while the page is open. It is a unitless score, not a time. A shift happens when, for example, an image loads without reserved space and pushes the text down, causing a visitor to tap the wrong link or lose their place.
- Set width and height (or an aspect ratio) on every image, video and iframe so the browser reserves space.
- Reserve fixed space for cookie banners, adverts and embeds rather than injecting them above content.
- Load web fonts in a way that avoids a large reflow when the font swaps in.
- Avoid inserting content above existing content unless it responds to a user action.
How are Core Web Vitals measured: field data or lab data?
Google assesses Core Web Vitals with field data: measurements from real Chrome users, collected in the Chrome User Experience Report (CrUX) over a rolling 28-day window. Lab tools such as Lighthouse simulate a single page load on a set device and network. Lab data helps you debug; field data decides whether you pass.
Low-traffic pages may not have enough CrUX data to be assessed individually. In that case Google may group similar URLs together, or no field data is shown at all, and lab tests become your main guide.
| Field data (real users) | Lab data (simulated) | |
|---|---|---|
| Source | Chrome User Experience Report (CrUX) | Lighthouse, Chrome DevTools |
| Where you see it | Search Console Core Web Vitals report, PageSpeed Insights (top section) | PageSpeed Insights (diagnostics section), DevTools |
| Measures INP? | Yes | No; Total Blocking Time is used as a lab proxy |
| Best for | Knowing whether real visitors have a good experience | Finding and testing the cause of a problem |
How do you check your site in Google Search Console?
Open the Core Web Vitals report under Experience in Google Search Console. It groups your URLs into good, needs improvement and poor for mobile and desktop, shows which metric is failing, and lists example URLs. After fixing an issue, use "Validate fix" to ask Google to monitor the group over the next 28 days.
- Start with the mobile report and the group of URLs with the most "poor" pages.
- Run an example URL through PageSpeed Insights to see field data and lab diagnostics side by side.
- Fix the cause on the template, not just one page, since URL groups usually share a template.
- Validate the fix in Search Console and recheck field data after the 28-day window.
Do Core Web Vitals affect Google rankings?
Yes, but modestly. Core Web Vitals are part of Google's page experience signals, which its ranking systems use alongside many others. Google is clear that relevant, helpful content matters more, so a fast page will not outrank a better answer. Good scores help most when competing pages are otherwise similar, and they improve conversions regardless.
The business case is usually as much about visitors as about rankings: slow, jumpy pages lose enquiries and sales. That is why speed sits alongside content and structure in our SEO services and our SEO-friendly website checklist.
How do you fix a site that fails Core Web Vitals?
Find which metric fails on which template, fix the root cause, then wait for field data to confirm it. Most failures come from heavy themes and page builders, oversized images, slow hosting and too many third-party scripts. Fixing those at template level usually lifts every page that shares the template.
Our step-by-step guide on how to improve website speed covers the practical fixes in more depth. If you would rather have it done for you, a professional speed audit checks your site against field data and fixes the causes. As a typical UK market guide, a speed audit with fixes costs around £500 to £3,000 excluding VAT.
If the real problem is an ageing theme that cannot be made fast, a website redesign on a lighter build may be cheaper in the long run than repeated patching.
Prices are indicative typical UK market ranges, excluding VAT, not a Freehand HQ quote.