Core Web Vitals: CWV That Actually Move Rankings
LCP, INP, CLS — what they measure, what they ignore, and the fixes Google rewards.
Core Web Vitals are the only confirmed ranking factor that lives in the page-experience cluster. They are also the most misunderstood. This guide cuts through the noise — what CWV actually measure, what they ignore, and the fixes that move the needle.
The three metrics
- LCP (Largest Contentful Paint): When the largest visible element renders. Target: < 2.5s.
- INP (Interaction to Next Paint): The slowest user interaction in a session. Target: < 200ms.
- CLS (Cumulative Layout Shift): Cumulative visual instability. Target: < 0.1.
Field data vs lab data
Google uses field data (real users on real devices, real network) for ranking. Lighthouse uses lab data (a synthetic mobile device on a throttled connection). Lab data is for debugging. Field data is the truth.
Sources of field data:
- Chrome User Experience Report (CrUX) — public, 28-day rolling.
- Search Console → Experience → Core Web Vitals — your own slice of CrUX.
- web-vitals.js library — first-party collection from your real users.
LCP fixes
The LCP element is usually one of three things:
- Hero image: Preload it.
<link rel="preload" as="image">. - Web font: Preload the font file. Use
font-display: optionalfor above-the-fold. - Render-blocking script: Defer, async, or remove.
Common secondary offenders: a CSS-in-JS runtime that blocks rendering, a third-party tag that loads synchronously, a CDN edge that misses on first byte.
INP fixes
INP is a measure of main-thread responsiveness. The fixes are systematic:
- Code-split. A 1MB main bundle is the leading cause of poor INP.
- Defer non-critical work. Use
requestIdleCallbackorscheduler.postTask. - Yield to the main thread. Long tasks over 50ms should be broken up with
scheduler.yield(). - Avoid heavy event handlers. Click handlers doing synchronous DOM work over 50ms fire a yellow flag in INP.
- Virtualize long lists. A 10,000-row table rendered all at once is an INP event waiting to happen.
CLS fixes
- Always specify image dimensions.
widthandheight, or aspect-ratio CSS. - Reserve space for embeds. Ads, iframes, and embeds should have a container with a fixed height.
- Preload web fonts.
size-adjuston the fallback. - Avoid injecting content above existing content. Banner notifications, cookie bars, anything.
The 75th-percentile rule
Google scores pages at the 75th percentile of users. Which means 25% of your real users can have terrible CWV without affecting your ranking — but only if your 75th percentile is at “good”. If you are at the threshold, a single slow day can flip you to “needs improvement”. Aim for the 90th percentile being “good”.
What CWV is not
- It is not a tiebreaker in head-to-head comparisons of equal-quality content.
- It does not override relevance.
- It does not save weak content.
- It does not penalize poor CWV — only rewards good CWV.
Wrap-up
CWV is a quality floor, not a ranking strategy. Get them to “good” and stop chasing milliseconds. The next tier of ROI is content depth, not INP from 180ms to 120ms.
Step-by-step
- 1
Pull field data
Open CrUX (Chrome User Experience Report) for your domain. Look at the 75th percentile over 28 days. That is the only number Google uses.
- 2
Diagnose LCP
LCP is usually hero image, hero text, or a render-blocking resource. Lighthouse and WebPageTest show you exactly which.
- 3
Diagnose INP
INP is the slowest interaction in a session. Use the Web Vitals extension to capture it. Then dig into event handlers with the Performance panel.
- 4
Diagnose CLS
CLS is cumulative layout shift. Web fonts, images without dimensions, late-injected ads. Each shift is a contributor.
- 5
Ship the fixes
Preload hero image, defer non-critical JS, code-split the rest, size containers, use font-display: optional.
- 6
Measure again
Wait 28 days for field data to refresh. Compare. Re-invest.