01 What changed in 2026
Core Web Vitals (CWV) are Google's user-experience metrics that influence ranking. They're not the biggest ranking factor, but they're a tiebreaker on competitive queries — and on slow sites, they're a meaningful drag on traffic.
The big shift you should know about: INP officially replaced FID in March 2024 as the responsiveness metric. If your last Core Web Vitals review was before that, your dashboard is still showing legacy data and you may have new failures you haven't seen.
02 The three metrics today
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading speed of the main content | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP | Responsiveness to interaction | ≤ 200ms | 200–500ms | > 500ms |
| CLS | Visual stability (layout shifts) | ≤ 0.1 | 0.1–0.25 | > 0.25 |
These thresholds apply at the 75th percentile of all page loads, measured separately for mobile and desktop. Hitting the threshold for the median user isn't enough — you need to hit it for three out of every four users.
03 LCP — Largest Contentful Paint
LCP measures how quickly the largest visible element on a page loads. On most pages, that's a hero image, a video poster, or a large block of text.
Highest-leverage LCP fixes
- Preload the LCP image. Add
<link rel="preload" as="image" href="/hero.webp">in the head. This tells the browser to fetch the LCP image before the HTML parser even reaches it. - Don't lazy-load the LCP image. Sounds obvious, but a surprising number of sites add
loading="lazy"to every image including the one above the fold. Native lazy-loading delays LCP measurably. - Serve images in WebP or AVIF. File-size savings of 30–60% over JPEG translate directly into faster LCP on slower connections.
- Reduce render-blocking CSS. Inline critical CSS for above-the-fold content; defer the rest.
- Use HTTP/2 or HTTP/3. Multiplexing means LCP-critical resources don't wait behind queue heads.
- Cache static assets aggressively. A
Cache-Control: max-age=31536000, immutableon hashed asset URLs eliminates network round-trips on repeat visits.
04 INP — Interaction to Next Paint
INP measures how quickly your page responds to user interaction — clicks, taps, key presses. It's the worst (longest) interaction during the page's session, not the first.
INP failures are almost always JavaScript problems. The browser is busy executing JS and can't repaint the screen for hundreds of milliseconds.
Highest-leverage INP fixes
- Break up long tasks. Any JS task running longer than 50ms is a bottleneck. Split into smaller chunks with
setTimeout,requestIdleCallback, orscheduler.yield()(where supported). - Defer non-critical third-party scripts. Analytics, chat widgets, A/B test scripts — all can be loaded with
deferor after main content. - Avoid heavy work in event handlers. A click handler that does 500ms of work blocks the next paint. Move heavy work to
requestIdleCallback. - Reduce DOM size. Pages with 5,000+ DOM nodes are inherently slower to update. Aim for under 1,500.
- Audit your CSS animations. Animating
top/left/width/heighttriggers layout recalc on every frame. Stick totransformandopacity.
05 CLS — Cumulative Layout Shift
CLS measures the sum of unexpected visual movements during page load. Things like: an image loads and pushes text down; a button moves just as you're tapping it; an ad slot expands and shoves the article out of frame.
Highest-leverage CLS fixes
- Always include width and height attributes on images. The browser can then reserve space before the image loads, preventing reflow. Or use CSS
aspect-ratio. - Reserve space for ads and embeds using
min-heighton their containers. - Don't insert content above existing content. Cookie banners that push the page down on load are textbook CLS killers. Use overlays, not inserts.
- Preload custom fonts to prevent FOIT (Flash of Invisible Text) and FOUT (Flash of Unstyled Text) from causing layout shifts when the font swaps in.
- Use CSS
contain: layout on containers whose content size is dynamic.
06 Measuring CWV correctly
There are two kinds of CWV data: field and lab.
Field data (also called RUM — Real User Monitoring) is what Google actually uses for ranking. It comes from real users on real devices and connections, aggregated in the Chrome User Experience Report (CrUX). Pull it from Search Console > Core Web Vitals report or PageSpeed Insights.
Lab data is a synthetic measurement run from a controlled environment (e.g. Lighthouse). It's useful for catching regressions during development but doesn't predict your CrUX scores. A page can score 95 in Lighthouse and still fail field CWV.
Always optimise against field data when possible. Lab data is for engineering iteration; field data is for SEO.
07 Where to focus your effort
If you're improving CWV from scratch, the priority order is:
- LCP first. The biggest win for the smallest investment. Image optimisation alone often takes a "Poor" LCP to "Good".
- CLS second. Mostly free wins (image dimensions, font preload).
- INP third. Often requires real engineering work (JS refactoring, third-party script audit), so address it after the easier wins.
Smart SEO Audit's performance check group flags pages with poor response time, large page weight, and oversize DOM — three of the underlying causes of CWV failures. Run an audit to see your worst offenders.
? Frequently asked questions
What are the Core Web Vitals thresholds in 2026?
LCP should be 2.5s or less, INP 200ms or less, and CLS 0.1 or less. These apply at the 75th percentile of page loads, measured separately for mobile and desktop — so you need to hit them for three out of every four users, not just the median one.
What replaced FID in Core Web Vitals?
INP (Interaction to Next Paint) officially replaced FID in March 2024 as the responsiveness metric. If your last review was before that, your dashboard may be showing legacy data and hiding new failures. INP measures the worst interaction delay during a session, and failures are almost always caused by long JavaScript tasks.
What's the difference between field and lab Core Web Vitals data?
Field data (real-user monitoring from the Chrome User Experience Report) is what Google actually uses for ranking — pull it from Search Console or PageSpeed Insights. Lab data (e.g. Lighthouse) is synthetic and useful for catching regressions in development, but a page can score 95 in Lighthouse and still fail field CWV.
→ Related guides
Keep going — these companion guides go deeper on related topics.