Core Web Vitals are three user experience metrics Google uses as ranking signals: Largest Contentful Paint (LCP) measures loading speed, Interaction to Next Paint (INP) measures interactivity, and Cumulative Layout Shift (CLS) measures visual stability. Pages must pass all three at the 75th percentile of real user data to qualify as "Good". Only 48% of mobile pages currently do.
Most site owners check their Core Web Vitals once, see a "Poor" LCP, and do nothing because fixing it sounds expensive. That's a mistake with a compounding cost. Google has confirmed these metrics as ranking signals since 2021, and their weight has increased as the Page Experience system matured. And there's a second reason that showed up after 2024: pages with LCP under 2.5 seconds are disproportionately represented in Google AI Overviews. The correlation is strong enough that we treat Core Web Vitals as an AI search readiness metric now, not just a traditional ranking factor.
DataForSEO data shows "core web vitals seo" pulls 140 monthly US searches at KD 66, with "do core web vitals affect seo" pulling another 40 at KD 27. High awareness, persistent confusion about what to actually do. This guide covers the mechanics and the fixes.
What Are Core Web Vitals and Why Do They Matter?
Core Web Vitals are a subset of Google's Page Experience signals, specifically the three metrics that best predict whether a user will have a frustrating experience on a page. Google selected them because they're measurable from real user data (via Chrome User Experience Report, or CrUX), correlate with actual user satisfaction, and are actionable by site owners.
The ranking signal works at the page level, not the domain level. A fast homepage doesn't help a slow product page. And the evaluation uses field data (real users' Chrome sessions) rather than lab data (synthetic lighthouse tests). This distinction matters enormously: a page can pass PageSpeed Insights in lab mode but fail Core Web Vitals in field data if real-world conditions (slower devices, variable network) produce worse results.
Google requires "Good" scores at the 75th percentile, meaning 75% of real visits to your page must meet the threshold. The 25th slowest percentile is intentionally included, you can't pass by optimising only for desktop users on fast connections.
What Is Largest Contentful Paint (LCP)?
LCP: Largest Contentful Paint
Time until the largest visible element (hero image, heading, or video poster) finishes rendering in the viewport.
LCP is the metric most sites fail. The LCP element is whatever the browser identifies as the largest content block in the viewport when the page loads, typically a hero image, an H1, or an above-the-fold video thumbnail. If that element loads slowly, LCP fails.
The most common LCP culprits, in order of frequency: render-blocking third-party scripts delaying the critical rendering path; large unoptimised hero images without loading="eager" and explicit dimensions; fonts loaded via @import in CSS (instead of link rel="preload"); and server response times over 600ms. Fix the server response time first. You can optimise images perfectly and still fail LCP if the Time to First Byte is 1.5s.
How to Fix LCP
- Preload the LCP image: Add
<link rel="preload" as="image" href="/hero.webp">to your<head>. This tells the browser to fetch the LCP element before parsing the rest of the DOM. - Use modern image formats: WebP reduces file size 25-34% over JPEG for equivalent quality. AVIF reduces it further but has lower browser support. Use WebP as the default, AVIF for progressive enhancement.
- Add explicit width and height on images: This prevents layout shifts and lets the browser allocate space before the image loads, which also improves CLS.
- Reduce server response time (TTFB): Target under 600ms. Use a CDN for static assets, enable server-side caching, and review database query performance if you're on a CMS.
- Remove render-blocking resources: Move non-critical JavaScript to
deferorasync. Inline critical CSS for above-the-fold content.
What Is Interaction to Next Paint (INP)?
INP: Interaction to Next Paint
The latency from user interaction (click, tap, or keypress) to the next visual response. Evaluates all interactions during a page visit, not just the first.
INP replaced First Input Delay (FID) in March 2024. FID only measured the delay before the browser could begin processing the first interaction. INP measures the total delay, from input to next paint, for all interactions during a session, then reports the worst interaction (or near-worst, to filter out statistical outliers).
And this change was significant for JavaScript-heavy sites. A React or Vue SPA might have a perfectly good FID score (because the main thread is free at page load) but a terrible INP score (because user interactions trigger heavy re-renders with 600ms paint delays). This is where most SPA-based marketing sites are getting tripped up in 2026.
How to Fix INP
- Break up long JavaScript tasks: Any JS task over 50ms blocks the main thread and delays paint. Use
scheduler.postTask()orsetTimeoutwith 0ms delay to break long tasks into smaller chunks that yield to the browser. - Reduce DOM size: A DOM with over 1,500 elements significantly slows style recalculation after interactions. Virtualise long lists (react-window, Tanstack Virtual) and lazy-render off-screen content.
- Optimise event handlers: Debounce input events, avoid synchronous layout reads inside event handlers (avoid
element.offsetHeightinside a click handler), and move expensive computations to Web Workers. - Defer third-party scripts: Analytics, chat widgets, and ad scripts that execute on interaction can block INP. Use Partytown or load them with
deferand avoid synchronous third-party event listeners on the main document.
What Is Cumulative Layout Shift (CLS)?
CLS: Cumulative Layout Shift
The sum of all unexpected layout shift scores during the entire page lifecycle. A score of 0.1 means elements shifted during 10% of the viewport area on average.
CLS is the most misunderstood metric. Developers think of it as images shifting on load, but the 2021 update changed CLS measurement to apply to the page's full lifetime, meaning late-loading ads, cookie banners, and sticky bars that push content down all contribute to the score even after the initial load.
The most common causes: images without explicit dimensions (browser doesn't reserve space, image loads and pushes content down); web fonts that swap in and reflow text; dynamically injected content above existing content (cookie banners are the worst offender); and late-loading embeds (YouTube iframes, Twitter cards) without reserved space.
How to Fix CLS
- Always include width and height on images and videos: This lets the browser calculate the aspect ratio and reserve space before the resource loads. Use
aspect-ratioCSS as a fallback for responsive images. - Preload web fonts with
font-display: optional: This prevents font swap flashes for non-critical fonts. For key brand fonts, usefont-display: swapwith preloading to minimise shift duration. - Reserve space for dynamic content: Cookie banners should slide in from the bottom (not push content down); ads should have a min-height container reserved; social embeds should use skeleton placeholders matching the embed's expected dimensions.
- Use CSS
transformfor animations: Animations usingtop,left, ormargintrigger layout recalculation. Animations usingtransform: translate()do not, they run on the GPU compositor thread without affecting layout.
How Do You Measure Core Web Vitals?
There are two measurement contexts and you need both. Lab data (synthetic tests) is fast and repeatable but doesn't reflect real-world conditions. Field data (real user measurements) is what Google actually uses for ranking, but it takes 28 days to aggregate and you can't test changes immediately.
| Tool | Data Type | Best For | Ranking Relevance |
|---|---|---|---|
| Google Search Console (Core Web Vitals report) | Field (CrUX) | Seeing actual ranking-relevant scores by URL group | Direct (this is what Google uses) |
| PageSpeed Insights | Both (field + lab) | Per-URL analysis with specific fix recommendations | Field section is ranking-relevant |
| Lighthouse (Chrome DevTools) | Lab only | Development iteration, diagnosing specific issues | Not direct (lab scores differ from field) |
| web.dev/measure | Lab (Lighthouse) | Quick public-facing score check | Not direct |
| CrUX API / BigQuery | Field | Large-scale audits across many URLs | Direct |
Start with Google Search Console's Core Web Vitals report. It groups your pages into "Good", "Needs Improvement", and "Poor" by URL group, and the "Poor" pages list is your priority queue. Then use PageSpeed Insights to diagnose specific issues per URL. Only use Lighthouse in DevTools to test fixes in isolation before deploying.
A green Lighthouse score does not mean good Core Web Vitals. Lab data and field data differ. The only score Google uses for ranking is the CrUX field data in Search Console. Always validate fixes by watching field data improve over the 28-day rolling window, not by chasing Lighthouse scores.
Do Core Web Vitals Affect AI Search Rankings?
Page experience signals, including Core Web Vitals, affect which pages get crawled by AI crawlers like GPTBot and ClaudeBot, and how deeply. A page with a 5-second LCP and heavy JavaScript rendering creates challenges for AI crawlers that don't execute JavaScript the same way Chrome does.
More directly: pages cited in Google AI Overviews show a strong statistical lean toward fast load times. The average LCP of AI Overview source pages in Google's 2025 data was 3.2 seconds (compared to the 4.4-second average for all indexed pages). That's not proof of a direct causal relationship, but it's consistent with Google preferring trustworthy, accessible sources, and Core Web Vitals are one proxy for that.
For the full technical framework, see our Technical SEO hub, which covers crawlability, indexation, and schema markup as part of the same AI-readiness stack. Fast pages get crawled more thoroughly, indexed faster, and cited more often in AI-generated answers. Treat Core Web Vitals as foundational, not optional.
Frequently Asked Questions About Core Web Vitals
Yes. Core Web Vitals are a confirmed Google ranking signal. Pages achieving Good scores across LCP (under 2.5s), INP (under 200ms), and CLS (under 0.1) receive a ranking benefit. The effect is most visible in competitive queries where other quality signals are roughly equal. They also correlate with AI Overview citation rates, making them a factor in AI search visibility.
Lighthouse uses lab data: a synthetic test from a single device/network combination. Core Web Vitals use CrUX field data: real measurements from Chrome users visiting your page across all their devices and connections, including slower phones and 4G networks. Real users on slower devices in varied network conditions produce worse scores than your development machine. This discrepancy is normal and expected. Fix based on field data, not lab scores.
CrUX data is aggregated over a rolling 28-day window, so improvements take up to 28 days to fully reflect in Google Search Console and PageSpeed Insights field data. You can track progress weekly, but don't expect the final score to stabilise until the full 28 days of post-fix user sessions have accumulated. For ranking changes, allow an additional 2-4 weeks after the CrUX score improves, as Google's indexing cycle introduces another lag.
Audit Your Page Speed
Check LCP, INP, and CLS scores with actionable recommendations for your specific URLs.
Run Speed Audit