Core Web Vitals: What They Measure and How to Improve

Core Web Vitals are three measurements Google uses to describe real-world page experience: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. You improve them by sending less to the browser, loading the main content first, keeping JavaScript work short, and reserving space for everything that appears on the page. Each metric has an official "good" threshold published by Google; check the current values on web.dev, since they are the authority and can be revised.

This guide explains what each metric means in plain terms, how to see your own results, and the fixes that make the biggest difference in practice. It deliberately avoids quoting benchmark numbers for typical sites, because results vary widely by audience, devices and networks.

Why they matter to a business

Slow, jumpy pages frustrate visitors, and frustrated visitors leave before they read, buy or enquire. Google also uses page experience signals as one of many inputs to ranking, though relevant, helpful content remains far more important. Treat Core Web Vitals as a quality measure for your visitors first and a search consideration second.

The three metrics

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element in the first screen, typically a hero image, a large heading or a block of text, to appear. It approximates "when did the main content show up?".

Common causes of poor LCP: slow server responses, large unoptimised hero images, render-blocking CSS and JavaScript, content that only appears after JavaScript fetches data, and web fonts that delay text.

Interaction to Next Paint (INP)

INP measures how quickly the page responds visually after a user interaction, such as a click, tap or key press, observed across the whole visit. It replaced First Input Delay as a Core Web Vital in March 2024. A poor INP feels like tapping a button and nothing happening for a moment.

Common causes of poor INP: long JavaScript tasks that block the main thread, heavy event handlers, large component trees re-rendering at once, and third-party scripts such as chat widgets and tag managers.

Cumulative Layout Shift (CLS)

CLS measures how much visible content unexpectedly moves while the page loads or updates. You have felt it when you go to tap a link and an advert pushes it down, so you tap the wrong thing.

Common causes of poor CLS: images and embeds without set dimensions, late-loading adverts or banners, content injected above existing content, and fonts that swap and change text size.

Field data vs lab data

This distinction trips up many teams. Field data comes from real visitors using real devices; Google's Chrome User Experience Report supplies it, and Search Console's Core Web Vitals report and PageSpeed Insights display it. Lab data comes from a controlled test such as Lighthouse run on your machine or in a build pipeline.

Lab tests are excellent for finding and fixing problems because they are repeatable. Field data is what actually counts, because it reflects your audience's phones and networks. A page can look fine in the lab and still struggle in the field. INP in particular depends on real interactions, so it can only be fully assessed with field data. Use lab tools to debug and field data to judge.

How to measure

• Search Console shows grouped URLs that need improvement, using field data where enough traffic exists.
• PageSpeed Insights shows field data for a URL when available, plus lab diagnostics.
• Chrome DevTools (Performance and Lighthouse panels) lets you trace slow tasks and layout shifts.
• The web-vitals JavaScript library lets you collect the metrics from your own users and send them to your analytics.

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

function send(metric) {
  navigator.sendBeacon(
    "/analytics/vitals",
    JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      page: location.pathname,
    })
  );
}

onLCP(send);
onINP(send);
onCLS(send);

Collecting your own data tells you which page templates and which device groups are hurting, so you fix the right things first.

Fixes that improve LCP

1. Improve server response. Cache pages, use a CDN, and fix slow database queries. Pre-built pages from static generation are fast to deliver; see our rendering guide.
2. Optimise the hero image. Use modern formats such as WebP or AVIF, serve sizes appropriate to the screen with srcset, and compress sensibly.
3. Do not lazy-load the main image. Lazy loading is for images below the fold. Give the LCP image a high fetch priority.
4. Preload critical resources such as the hero image and key fonts.
5. Remove render-blocking work. Inline critical CSS, defer non-essential scripts, and avoid loading large frameworks for a simple page.
6. Avoid client-only rendering of main content. If the main text appears only after JavaScript fetches data, LCP suffers.

<img
  src="https://example.com/images/hero-800.webp"
  srcset="/images/hero-480.webp 480w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 800px) 100vw, 800px"
  width="1200" height="630"
  fetchpriority="high"
  alt="Team reviewing a project plan">

Fixes that improve INP

1. Ship less JavaScript. Remove unused libraries, split code by route, and load features only when needed.
2. Break up long tasks. Work that blocks the main thread for a long time delays every tap. Split it into smaller chunks and yield back to the browser between them.
3. Keep event handlers light. Do the minimum to update the screen, then move heavy computation off the critical path or into a Web Worker.
4. Control re-rendering. In React, avoid updating large parts of the tree for small changes, and memoise expensive components where profiling shows benefit.
5. Audit third-party scripts. Tag managers, chat widgets and trackers often account for a surprising share of main-thread time. Remove what you do not use and load the rest late.

Fixes that improve CLS

1. Set width and height (or use CSS aspect-ratio) on images, videos and iframes so the browser reserves space.
2. Reserve space for adverts, banners and embeds, even before they load.
3. Insert new content below the fold or in response to a user action, not above content someone is already reading.
4. Handle fonts carefully. Preload key fonts, use font-display thoughtfully, and choose a fallback font with similar metrics so text does not jump when the web font arrives.
5. Animate with transform and opacity rather than properties that change layout.

A sensible order of work

1. Look at field data and list the page types that fail.
2. Reproduce the problem in the lab on a throttled mobile profile.
3. Fix the biggest single cause per metric before polishing small ones.
4. Re-test, then wait for field data to catch up; it is collected over a rolling period, so improvements appear gradually.
5. Add a performance budget and automated checks to your build so regressions are caught before release.

Common mistakes

• Chasing a perfect Lighthouse score instead of real-user results.
• Testing only on a fast office laptop and connection. Your visitors may be on mid-range phones.
• Lazy-loading everything, including the hero image.
• Adding a heavy library to fix a small problem, which worsens INP.
• Ignoring third-party scripts because "marketing added them".
• Fixing once and never monitoring. New features and new tags slowly undo gains.
• Treating it as a developer-only task. Content choices such as autoplay video, huge images and many embeds are equally decisive.

Performance and accessibility often improve together: reserving space, using real HTML elements and avoiding unnecessary scripts help everyone. See web accessibility basics for the overlap.

Need a hand?

Performance work is most effective when it is part of how the product is built, not a rescue job before launch. Our team treats performance optimisation as a deliverable in web application development, from choosing the right rendering approach to setting up monitoring. If your current site or app is slow, we can start with an audit of the real causes.