Google introduced Core Web Vitals to put numbers on something users feel instinctively: does the page show up quickly, does it react when I tap, and does it stop jumping around? Since March 2024 the three metrics are LCP, INP and CLS. They are part of Google’s page experience signals, and more importantly, they correlate with whether people stay on your site.
The three metrics at a glance
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP – Largest Contentful Paint | Loading: when the main content appears | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s |
| INP – Interaction to Next Paint | Responsiveness to clicks, taps and key presses | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS – Cumulative Layout Shift | Visual stability: unexpected movement | ≤ 0.1 | 0.1–0.25 | > 0.25 |
A page passes when all three are in the good range at the 75th percentile of visits, measured separately for mobile and desktop. The 75th percentile means three out of four visits must be at least that good, so a fast experience for you on office Wi-Fi doesn’t count for much.
Field data vs lab data
- Field data (real user monitoring) comes from the Chrome UX Report (CrUX): anonymised measurements from real Chrome users over a rolling 28-day window. This is what Search Console’s Core Web Vitals report and Google’s assessment use.
- Lab data comes from a simulated test, such as Lighthouse or our website speed test, run on a defined device and network. It’s reproducible and great for debugging, but it cannot measure INP directly because no real user is interacting; it uses Total Blocking Time as a proxy.
Use field data to know whether you have a problem and lab data to find why. Because CrUX uses 28 days of data, a fix takes up to four weeks to fully show up in Search Console.
LCP: Largest Contentful Paint
LCP marks when the biggest visible element in the viewport finishes rendering, usually a hero image, a large heading or a video poster. It breaks down into four parts: server response (TTFB), resource load delay, resource load time and render delay.
How to improve LCP:
- Speed up the server: page caching, a better host or a CDN to cut TTFB.
- Make the LCP image discoverable early: use a normal
<img>in the HTML, not a CSS background or a JavaScript-injected image. - Prioritise it:
fetchpriority="high"on the hero image and noloading="lazy"on it. - Shrink it: right dimensions, WebP or AVIF, sensible compression.
- Remove render-blocking resources: large CSS files and synchronous scripts in the
<head>delay the first paint.
<img src="/img/hero-1200.avif" width="1200" height="600"
fetchpriority="high" alt="Product dashboard">INP: Interaction to Next Paint
INP observes every click, tap and key press during a visit and reports roughly the worst one (ignoring outliers on pages with many interactions). It measures the time from the interaction to the next frame being painted, so it includes waiting for the main thread, running your event handlers, and rendering the result.
Typical causes of poor INP:
- Long JavaScript tasks (over 50 ms) blocking the main thread, often from analytics, ads, chat widgets or a heavy framework hydrating the page.
- Event handlers doing too much work synchronously, e.g. filtering a 5,000-item list on every keystroke.
- Huge DOM sizes that make each re-render expensive.
How to improve INP:
- Remove or delay third-party scripts that aren’t essential.
- Break long tasks into smaller chunks and yield to the main thread (
await scheduler.yield()where supported, orsetTimeout). - Give immediate visual feedback, then do the heavy work afterwards.
- Debounce input handlers and avoid layout thrashing (reading and writing layout in a loop).
CLS: Cumulative Layout Shift
CLS scores how much visible content moves unexpectedly. Clicking the wrong button because an ad pushed everything down is the classic example. Shifts within 500 ms of a user interaction don’t count.
Common causes and fixes:
| Cause | Fix |
|---|---|
| Images and iframes without dimensions | Add width and height or CSS aspect-ratio |
| Ads, embeds and cookie banners injected late | Reserve space with a fixed-height container; show banners as overlays |
| Web fonts swapping and changing text size | Preload the main font; use size-adjust / fallback metrics |
| Content inserted above existing content | Insert below, or only after user action |
Animating top/height |
Animate transform and opacity instead |
How to work through it
- Open Search Console → Core Web Vitals to see which URL groups fail on mobile and desktop.
- Pick one template (e.g. product pages) and run a lab test to find the LCP element, long tasks and shifting elements.
- Fix the biggest cause first, usually the hero image or a third-party script.
- Validate the fix in Search Console and wait for the 28-day window to roll over.
- Monitor after every redesign, new plugin or new marketing tag.
For broader optimisation beyond these three metrics, see how to speed up your website.
Common misconceptions
- “A Lighthouse score of 100 means I pass.” Not necessarily: the assessment uses field data from real users.
- “Desktop is fine, so we’re fine.” Mobile is assessed separately and usually much worse.
- “CWV is the main ranking factor.” It is one signal among many; relevant, helpful content comes first. Treat CWV as a user-experience and conversion issue as much as an SEO one.