Core Web Vitals

Core Web Vitals are Google’s standardized metrics for measuring real-world user experience. They are included in Google’s search ranking algorithm and are the closest thing the industry has to an official definition of “fast.” Unlike synthetic benchmarks, they measure what the user actually experiences during a page load and interaction.

The Three Vitals

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest image or text block in the viewport to render. It approximates how quickly the page feels “loaded” to the user.

Common causes of poor LCP:

• Slow server response time (TTFB > 600 ms)
• Render-blocking CSS or JavaScript delaying the LCP element
• LCP image is not preloaded and discovered late in the HTML
• LCP image is not sized or compressed correctly

Fixes:

• Preload the LCP image with <link rel="preload" as="image">
• Never lazy-load the LCP image (loading="lazy" on the hero)
• Serve images in WebP/AVIF from a CDN with long cache TTL
• Use server-side rendering or SSG to reduce TTFB

Cumulative Layout Shift (CLS)

CLS measures unexpected visual movement. Every time an element shifts its position unexpectedly, the shift contributes to the CLS score (impact fraction × distance fraction).

Common causes:

• Images without width and height attributes (browser cannot reserve space)
• Ads, embeds, or iframes injected without reserved dimensions
• Web fonts causing FOUT (Flash of Unstyled Text) that reflows layout
• Dynamically injected banners above existing content

Fixes:

<!-- Always set width and height so the browser reserves space -->
<img src="photo.jpg" width="800" height="450" alt="...">

/* Reserve space for dynamic content with aspect-ratio */
.ad-slot { width: 300px; aspect-ratio: 300 / 250; }

Interaction to Next Paint (INP)

INP replaced FID (First Input Delay) in March 2024. It measures the latency of all interactions (clicks, taps, keyboard input) across the full page lifetime and reports the worst one (with some outlier trimming). It includes processing time and rendering delay — not just input latency.

Common causes:

• Long JavaScript tasks blocking the main thread
• Expensive event handlers (synchronous DOM reads + writes causing forced reflow)
• Hydration spikes in React/Vue SSR applications
• Third-party scripts (analytics, tag managers) hogging the main thread

Fixes:

• Break up long tasks with scheduler.yield() or setTimeout(..., 0)
• Defer non-critical third-party scripts until after load
• Move expensive computation to a Web Worker
• Use startTransition in React to mark non-urgent state updates

Measuring Core Web Vitals

Lighthouse (Lab Data)

Run in Chrome DevTools → Lighthouse tab, or via the CLI (npx lighthouse <url>). Lab data is reproducible and great for CI, but it simulates a single mid-tier device and cannot capture INP.

CrUX (Field Data)

The Chrome User Experience Report (CrUX) aggregates real user measurements from Chrome browsers. Access it via:

• PageSpeed Insights (pagespeed.web.dev) — combines Lab (Lighthouse) and Field (CrUX) data
• Google Search Console → Core Web Vitals report — shows pass/fail breakdown for your entire site
• CrUX Dashboard — BigQuery export for custom analysis

web-vitals JavaScript Library

Collect field data from your own users and send it to your analytics:

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

onLCP(({ value, rating }) => {
  analytics.track("core_web_vital", { metric: "LCP", value, rating });
});

Further Learning

Search these terms to go deeper:

• “web.dev vitals” — the canonical explainer for each metric from the Chrome team
• “CrUX dashboard Google Data Studio” — how to explore field data for your site over time
• “INP optimization guide web.dev” — deep dive into interaction latency and main-thread scheduling
• “Lighthouse CI GitHub Actions” — enforcing performance budgets on every pull request
• “web-vitals npm library” — how to measure and report field data from real users

Core Web Vitals

Core Web Vitals are three scores Google uses to measure how good your page feels to real users. They even affect your Google search ranking. Each one captures a different frustration: waiting, jumping, and lagging.

The three scores

LCP — how fast the main content shows up

Largest Contentful Paint measures how long until the biggest thing on screen (usually the hero image or headline) appears. Basically: “how long until it looks loaded?”

• 🟢 Good: under 2.5 seconds

Common cause: a big, unoptimized hero image. Fix: compress it, use WebP, and don’t lazy-load it.

CLS — does the page jump around?

Cumulative Layout Shift measures annoying movement — like when you go to tap a button and an image loads, shoving everything down.

• 🟢 Good: under 0.1

Common cause: images and ads without reserved space. Fix: always set width and height on images so the browser holds the spot:

<img src="photo.jpg" width="800" height="450" alt="..." />

INP — does it respond quickly when you tap?

Interaction to Next Paint measures the lag between you clicking/tapping and the page reacting. Basically: “does it feel snappy or sluggish?”

• 🟢 Good: under 200 milliseconds

Common cause: heavy JavaScript hogging the browser. Fix: break big tasks into smaller pieces and defer non-essential scripts.

How to measure them

• Lighthouse (in Chrome DevTools → Lighthouse tab) gives you a quick lab score anytime.
• PageSpeed Insights (pagespeed.web.dev) shows both lab scores and real-user data from actual Chrome users.

Run one of these on your page and you’ll get a clear report card with the three vitals and suggested fixes.

In one sentence

Core Web Vitals score three feelings — LCP (how fast content appears, aim under 2.5s), CLS (how much the page jumps, aim under 0.1), and INP (how fast it responds to taps, aim under 200ms) — measured easily with Lighthouse or PageSpeed Insights.

Want to go deeper?

Switch to Expert mode above for the full threshold tables, detailed causes and fixes for each vital, and measuring real-user data with the web-vitals library.