Core Web Vitals: The Complete Guide

What are Core Web Vitals?

Core Web Vitals are Google's page experience metrics — a set of three measurements that quantify how users experience the speed, responsiveness, and stability of a web page.

They are:

1. LCP (Largest Contentful Paint) — measures loading performance
2. INP (Interaction to Next Paint) — measures interactivity and responsiveness
3. CLS (Cumulative Layout Shift) — measures visual stability

Google uses these metrics as ranking signals. According to Google's page experience documentation, pages that provide a good experience (passing all three vitals) may rank higher than pages that do not, all else being equal. Core Web Vitals are not the most important ranking factor — relevance and authority matter more — but they are a factor, and they directly affect user experience and conversion rates.

The three Core Web Vitals explained

LCP: Largest Contentful Paint

What it measures: The time it takes for the largest content element in the viewport (the visible area of the page) to render. This is usually a hero image, a large heading, or a video poster.

Why it matters: LCP is a proxy for perceived loading speed. When the largest element renders, the user perceives the page as "loaded" — even if other elements are still loading.

Thresholds (per web.dev's LCP documentation):

• Good: under 2.5 seconds
• Needs improvement: 2.5–4 seconds
• Poor: over 4 seconds

What affects LCP:

INP: Interaction to Next Paint

What it measures: The time from when a user interacts with the page (clicks, taps, key presses) to when the browser next paints the visual response. INP reports the worst (or near-worst) interaction on the page.

Why it matters: INP measures how responsive the page feels. When a user clicks a button and nothing happens for 500ms, the page feels broken. INP captures this.

Thresholds (per web.dev's INP documentation):

• Good: under 200ms
• Needs improvement: 200–500ms
• Poor: over 500ms

What affects INP:

• JavaScript execution time (the most common cause)
• Long tasks (anything over 50ms blocks interaction)
• Event handler complexity
• Third-party scripts (analytics, chat, ads)
• Main thread congestion

CLS: Cumulative Layout Shift

What it measures: The total amount of visible layout shift that occurs during the page's lifetime. Every time an element moves (not because the user scrolled, but because content loaded late and pushed other content), it counts as a layout shift.

Why it matters: Layout shift is frustrating. When a button moves as you are about to click it, you click the wrong thing. When text reflows as an image loads, you lose your place. CLS measures this frustration.

Thresholds (per web.dev's CLS documentation):

• Good: under 0.1
• Needs improvement: 0.1–0.25
• Poor: over 0.25

What affects CLS:

• Images without dimensions (load and push content down)
• Ads and embeds without reserved space
• Dynamically injected content (banners, pop-ups)
• Web fonts causing text reflow (FOUT — flash of unstyled text)
• Async CSS loading

How to measure Core Web Vitals

Lab data vs. field data

There are two types of Core Web Vitals data:

• Lab data — measured in a controlled environment (simulated device, simulated network). Good for diagnosing issues and testing fixes. Does not reflect real user experience.
• Field data — measured from real users (via the Chrome UX Report). Reflects actual user experience across devices and networks. This is what Google uses for ranking.

Always check both. Lab data helps you find and fix issues; field data tells you if your fixes worked for real users.

Tools for measuring Core Web Vitals

#### PageSpeed Insights

The easiest tool for checking any URL:

1. Go to pagespeed.web.dev
2. Enter your URL
3. Review both lab data (Lighthouse) and field data (Chrome UX Report)

PageSpeed Insights shows LCP, INP, CLS, and other metrics, plus specific recommendations for improvement.

#### Google Search Console

The Core Web Vitals report shows site-wide status:

• Which URLs are good, needs improvement, or poor
• Mobile and desktop breakdown
• Historical trends

Check this report monthly to monitor site-wide performance.

#### Lighthouse (Chrome DevTools)

Run Lighthouse in Chrome DevTools for detailed lab data:

1. Open Chrome DevTools (F12)
2. Go to the Lighthouse tab
3. Run a performance audit

Lighthouse provides a performance score and detailed diagnostics for each metric.

#### Chrome UX Report

Field data from real Chrome users:

• Available via the CrUX dashboard
• Shows field data for your domain
• Updated monthly

#### Web Vitals JavaScript library

For custom monitoring:

import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(console.log);
onINP(console.log);
onCLS(console.log);

This lets you measure Core Web Vitals in your analytics or monitoring tool.

Optimizing LCP (Largest Contentful Paint)

LCP is usually dominated by the largest above-the-fold element — most often a hero image. Here is how to optimize it.

1. Optimize the LCP element

Identify the LCP element using PageSpeed Insights or Lighthouse. Then:

• If it is an image:

- Serve it in WebP or AVIF format (smaller file size)
- Compress it appropriately (balance quality and file size)
- Size it correctly (do not serve a 2000px image for a 500px display)
- Use responsive images with srcset
- Preload it: <link rel="preload" as="image" href="hero.jpg">

• If it is text:

- Ensure the font loads quickly (preconnect to font origins)
- Use font-display: swap or optional
- Avoid render-blocking CSS that delays text rendering

2. Reduce server response time (TTFB)

Time to First Byte affects when the browser can start rendering:

• Use a CDN for global delivery
• Use caching (page caching, object caching, CDN caching)
• Optimize database queries
• Use server-side rendering or static generation
• Upgrade your hosting (shared → VPS → dedicated)

Target: TTFB under 600ms.

3. Eliminate render-blocking resources

CSS and JavaScript in the head block rendering:

• CSS: inline critical CSS in the head, defer non-critical CSS
• JavaScript: add defer or async to non-critical scripts
• Fonts: preconnect to font origins, use font-display: swap
• Third-party scripts: load non-critical third-party scripts asynchronously

4. Use resource hints

Resource hints tell the browser to start loading resources before they are needed:

• Preload — load a resource immediately (for the LCP element): <link rel="preload" as="image" href="hero.jpg">
• Preconnect — establish a connection to a third-party origin: <link rel="preconnect" href="https://fonts.googleapis.com">
• DNS-prefetch — resolve DNS for a third-party origin: <link rel="dns-prefetch" href="https://cdn.example.com">
• Prefetch — load a resource for the next navigation (low priority)

Optimizing INP (Interaction to Next Paint)

INP is usually caused by JavaScript execution. Here is how to optimize it.

1. Reduce JavaScript execution time

• Code-split — load only the JavaScript needed for the current page
• Tree-shake — remove unused JavaScript from your bundle
• Minify — reduce file size by minifying JavaScript
• Defer non-critical JavaScript — load non-critical scripts after the page is interactive
• Use modern frameworks efficiently — Next.js, Nuxt, and SvelteKit have built-in optimizations

2. Break up long tasks

Any task over 50ms blocks interaction. Break up long tasks:

• Use setTimeout or requestIdleCallback to yield to the main thread
• Use web workers for heavy computation (off the main thread)
• Split large data processing into chunks
• Use scheduler.yield() (where supported) for better yielding

// Break up a long task
async function processLargeData(data) {
  for (const chunk of chunkArray(data, 100)) {
    processChunk(chunk);
    await scheduler.yield(); // Yield to the main thread
  }
}

3. Optimize event handlers

• Debounce scroll and resize handlers — do not run expensive code on every scroll event
• Use passive event listeners — for scroll and touch events: addEventListener('scroll', handler, { passive: true })
• Avoid synchronous layout reads — reading offsetWidth after writing styles forces a synchronous layout (layout thrashing)
• Minimize handler complexity — keep event handlers lean

4. Reduce third-party scripts

Third-party scripts (analytics, chat, ads) are a major cause of poor INP:

• Audit your third-party scripts — do you need all of them?
• Load them asynchronously — do not let them block the main thread
• Delay them — load non-critical third-party scripts after the page is interactive
• Use a tag manager — Google Tag Manager can defer and conditionally load tags
• Use a third-party proxy — services like Cloudflare Zaraz or Partytown run third-party scripts in a web worker

Optimizing CLS (Cumulative Layout Shift)

CLS is caused by late-loading resources shifting layout. Here is how to prevent it.

1. Set explicit dimensions on images and videos

The most common cause of CLS is images loading without dimensions:

<!-- Bad: no dimensions, image pushes content down when it loads -->
<img src="hero.jpg" alt="Hero">

<!-- Good: dimensions set, space reserved before image loads -->
<img src="hero.jpg" alt="Hero" width="800" height="600">

For responsive images, use aspect-ratio CSS:

img {
  width: 100%;
  height: auto;
  aspect-ratio: 4 / 3;
}

2. Reserve space for ads and embeds

Ads and embeds that load late cause significant layout shift:

• Reserve space — use a fixed-size container for ads and embeds
• Use CSS min-height — reserve space with min-height on the container
• Lazy-load below the fold — do not load ads and embeds until they are near the viewport

.ad-container {
  min-height: 250px; /* Reserve space for the ad */
}

3. Avoid inserting content above existing content

When content is inserted above existing content, everything shifts down:

• Do not push banners on top of content — load banners before content or in reserved space
• Do not dynamically inject content above the fold — if you must, reserve the space first
• Use CSS transform for animations — transforms do not cause layout shift (they use the compositor)

4. Prevent font reflow (FOUT)

When web fonts load, text may reflow from the fallback font to the web font:

• Use font-display: optional — the browser uses the web font only if it is already loaded (no reflow)
• Use font-display: swap — the browser shows the fallback immediately and swaps when the web font loads (some reflow)
• Preload fonts — <link rel="preload" as="font" href="font.woff2" crossorigin>
• Use a fallback font that matches the web font — match size, weight, and spacing to minimize reflow

5. Use CSS containment

CSS containment tells the browser that a section of the page is independent:

.sidebar {
  contain: layout; /* Layout changes in this element do not affect the rest of the page */
}

This can prevent layout shifts from propagating.

Core Web Vitals and ranking

How Google uses Core Web Vitals

Core Web Vitals are part of Google's "page experience" signals, which include:

• Core Web Vitals (LCP, INP, CLS)
• Mobile-friendliness
• HTTPS
• No intrusive interstitials

Google uses page experience as a tiebreaker — when two pages are similarly relevant and authoritative, the one with better page experience may rank higher. Core Web Vitals alone will not make a poor page rank, but poor vitals can hold back an otherwise good page.

Field data is what matters

Google uses field data (from the Chrome UX Report) for ranking, not lab data. This means:

• Your lab scores do not directly affect rankings — only field data does
• You need real users to generate field data — new pages will not have field data immediately
• Field data is aggregated monthly — changes take time to reflect in rankings
• Optimize for the 75th percentile — Google evaluates the experience of the 75th percentile of users

The mobile-first focus

Google uses mobile-first indexing and evaluates Core Web Vitals primarily on mobile:

• Optimize for mobile first — mobile is harder (slower networks, less powerful devices)
• Then check desktop — desktop should also meet thresholds
• Test on real mobile devices — not just emulated mobile in lab tools

Common Core Web Vitals mistakes

• Optimizing lab scores, not field data — lab data does not affect rankings; field data does
• Ignoring the LCP element — optimizing everything except the one element that determines LCP
• Not preloading the hero image — the single most effective LCP optimization
• Too much JavaScript — the most common cause of poor INP
• No image dimensions — the most common cause of poor CLS
• Third-party script overload — analytics, chat, and ads blocking the main thread
• Not testing on mobile — desktop scores do not reflect mobile experience
• Set-and-forget — Core Web Vitals can regress as content and scripts change

The bottom line

Core Web Vitals are not the most important SEO factor — relevance and authority matter more. But they are a factor, and they directly affect user experience and conversion rates. A fast, responsive, stable page ranks better and converts better.

The good news: the optimizations are well-documented and achievable. Identify your LCP element and preload it. Reduce your JavaScript and break up long tasks. Set dimensions on your images and reserve space for ads. Measure with field data, not just lab data, and optimize for the 75th percentile of real users.

Do this, and your pages will not just rank better — they will provide an experience that keeps users engaged and converting.

Sources & Further Reading

• web.dev — Core Web Vitals overview

Google's official overview of Core Web Vitals, including metric definitions and thresholds.
web.dev/articles/vitals

• web.dev — LCP (Largest Contentful Paint)

Official documentation defining LCP, its thresholds, and optimization strategies.
web.dev/articles/lcp

• web.dev — INP (Interaction to Next Paint)

Official documentation defining INP, which replaced FID as a Core Web Vital in March 2024.
web.dev/articles/inp

• web.dev — CLS (Cumulative Layout Shift)

Official documentation defining CLS, its thresholds, and how to prevent layout shifts.
web.dev/articles/cls

• Google Search Central — Page experience

Documentation on how page experience signals (Core Web Vitals, mobile-friendliness, HTTPS, intrusive interstitials) affect rankings.
developers.google.com/search/docs/appearance/page-experience

• PageSpeed Insights

Google's official tool for measuring Core Web Vitals with both lab and field data.
pagespeed.web.dev