Core Web Vitals Explained: LCP, INP and CLS in Practice

Core Web Vitals are Google's attempt to put numbers on something users feel instinctively: whether a page loads quickly, responds when you tap it, and stays still while you read. They have become a standard part of technical SEO conversations, yet they are widely misunderstood. Some site owners treat them as a ranking silver bullet. Others chase perfect lab scores that have little to do with what real visitors experience.

This guide explains the three metrics in plain terms, how they are measured, where to find your data, and, most importantly, the practical fixes that move each metric. We include code examples you can adapt, and we are honest about how much Core Web Vitals influence rankings, because setting realistic expectations is part of prioritizing the work well.

What Core Web Vitals are

Core Web Vitals are a subset of Google's broader Web Vitals initiative, focused on three aspects of user experience that apply to almost every page on the web.

Largest Contentful Paint (LCP)

LCP measures loading performance: the time from when the user starts navigating to the page until the largest image or text block in the viewport is rendered. Typical LCP elements are hero images, large headings, the first paragraph of an article, video poster images or background images loaded through CSS.

Interaction to Next Paint (INP)

INP measures responsiveness. It observes the latency of clicks, taps and key presses throughout the whole visit and reports a value close to the worst interaction, ignoring rare outliers on pages with many interactions. An interaction's latency covers the input delay before event handlers run, the time spent processing those handlers, and the delay until the browser paints the next frame. INP officially replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the delay of the first interaction, which made it too easy to pass.

Cumulative Layout Shift (CLS)

CLS measures visual stability: how much visible content moves unexpectedly during the page's life. Each unexpected shift is scored by how much of the viewport moved and how far it moved. Shifts are grouped into session windows, and CLS reports the largest window. Shifts that happen within a short time after a user interaction, such as expanding an accordion, are excluded because the user expected them.

Thresholds and how pages pass

Google publishes three bands for each metric. A URL (or group of similar URLs) is assessed at the 75th percentile of page loads, segmented by mobile and desktop. In other words, at least three out of four visits need to meet the "good" threshold for that metric to be rated good.

The 75th percentile matters. Your own experience on a fast laptop and fiber connection says little about the visitor on a mid-range phone over a congested mobile network. The percentile approach deliberately weights the experience of slower devices and connections, which is where most real problems show up.

Field data vs lab data

This distinction causes more confusion than any other part of Core Web Vitals, so it is worth being precise.

• Field data (real user monitoring) is collected from actual visitors on real devices and networks. It reflects what people truly experience, but it is aggregated over time and can be hard to debug directly.
• Lab data is collected in a controlled environment, such as Lighthouse running a simulated mid-range mobile device on a throttled connection. It is reproducible and great for debugging, but it is a single synthetic scenario.

Lab tools cannot measure INP directly because there is no real user interacting with the page. Lighthouse reports Total Blocking Time (TBT) instead, which correlates with responsiveness problems caused by main-thread work during load. A good TBT is a helpful indicator, not a guarantee of good INP.

Where to find your data: CrUX, PageSpeed Insights and Search Console

Chrome User Experience Report (CrUX)

CrUX is Google's public dataset of real-user experience from eligible Chrome users who have opted in. It powers the field data you see in Google's tools and is the source Google uses for page experience evaluation. Data is aggregated over a rolling 28-day window, so improvements take several weeks to be fully reflected. Pages and origins need enough traffic to appear in the dataset; low-traffic URLs may show no field data at all.

PageSpeed Insights

PageSpeed Insights shows both field data from CrUX (for the URL and for the whole origin, where available) and a Lighthouse lab audit with specific diagnostics. It is the quickest way to check a single page and see whether it passes the assessment.

Search Console Core Web Vitals report

The Core Web Vitals report in Search Console groups similar URLs together and shows which groups are good, need improvement or are poor on mobile and desktop. It is the best starting point for a whole site because it shows you patterns: often an entire template, such as product pages or blog posts, shares the same problem.

Your own real user monitoring

For faster feedback and richer debugging, collect your own field data with Google's open-source web-vitals JavaScript library, sending results to your analytics. Its attribution build tells you which element was the LCP, which interaction was slowest and which elements shifted.

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

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    page: location.pathname,
    debug: metric.attribution
  });
  navigator.sendBeacon('/analytics', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Fixing Largest Contentful Paint

It helps to break LCP into four parts: time to first byte (TTFB), the delay before the browser starts loading the LCP resource, the time to download that resource, and the delay before the element renders. Diagnostics in PageSpeed Insights and Chrome DevTools show these subparts, which tells you where to focus.

Reduce server response time (TTFB)

Nothing can render until the HTML arrives. Slow TTFB often comes from uncached dynamic pages, slow database queries, heavy plugins, redirect chains or distant servers. Full-page caching, a CDN, fewer redirects and efficient server-side code usually deliver the biggest single improvement. web.dev suggests aiming for a TTFB of roughly 0.8 seconds or less as a rough guide.

Make the LCP image discoverable and prioritized

The browser should find the LCP image in the initial HTML and fetch it immediately. Common mistakes include loading the hero image through JavaScript, setting it as a CSS background the browser discovers late, or lazy-loading it.

<!-- Good: discoverable in HTML, high priority, not lazy-loaded -->
<img src="/images/hero-1200.webp"
     srcset="/images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
     sizes="100vw"
     width="1200" height="600"
     fetchpriority="high"
     alt="Team reviewing a site performance report">

The fetchpriority="high" attribute tells the browser this image matters more than others it finds. Only use it on one or two genuinely critical resources; marking everything as high priority cancels the benefit.

Preload late-discovered resources

If the LCP image must be referenced from CSS, or a critical font is needed for LCP text, a preload hint lets the browser start fetching early.

<link rel="preload" as="image"
      href="/images/hero-1200.webp"
      fetchpriority="high">

Remove render-blocking CSS and JavaScript

Stylesheets in the <head> block rendering, as do synchronous scripts. Inline the small amount of critical CSS needed for above-the-fold content, load non-critical styles later, remove unused CSS, and add defer to scripts that do not need to run before first render.

Optimize the resource itself

• Serve modern formats such as WebP or AVIF, and size images for the display they are shown on using srcset.
• Compress images sensibly; hero images rarely need maximum quality.
• Avoid client-side rendering for main content where possible. Server-rendered or static HTML lets the LCP element appear without waiting for JavaScript.

Fixing Interaction to Next Paint

INP problems almost always come down to the browser's main thread being busy when the user tries to interact, or event handlers doing too much work before the screen can update.

Find long tasks

Any task that occupies the main thread for more than 50 milliseconds is considered a long task. While it runs, the browser cannot respond to input. Use the Performance panel in Chrome DevTools to record an interaction and look for long tasks, then identify which scripts caused them. Field attribution data from the web-vitals library tells you which interactions and elements were slowest in real visits, so you know where to look.

Break up long tasks and yield to the main thread

The core technique is to split work into smaller chunks and give the browser a chance to handle input and paint between them. The scheduler.yield() API is designed for this; where it is not supported, a setTimeout fallback works.

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function processItems(items) {
  for (const item of items) {
    processItem(item);
    await yieldToMain();
  }
}

Do the visual update first

When a user clicks, update the interface immediately (show the menu, toggle the state, display a spinner), then defer non-essential work such as analytics calls or recalculations until after the next paint. Users judge responsiveness by the visual feedback, not by when background work finishes.

button.addEventListener('click', async () => {
  menu.classList.toggle('open');   // visible feedback first
  await yieldToMain();
  trackMenuClick();                // non-urgent work afterwards
});

Reduce and control JavaScript

• Ship less JavaScript: remove unused libraries, split bundles by route, and load features only when needed.
• Avoid large, synchronous DOM updates. Rendering thousands of elements at once is expensive; paginate or virtualize long lists.
• Watch hydration cost in JavaScript frameworks, which can block interactions shortly after load.

Audit third-party scripts

Tag managers, chat widgets, A/B testing tools, ad scripts and social embeds frequently cause long tasks. List every third-party script, confirm who owns it and whether it is still needed, and load what remains with defer or after user interaction where possible. Removing one unused tag can do more for INP than weeks of code optimization.

Fixing Cumulative Layout Shift

Always set dimensions on media

Images, videos and iframes without width and height attributes take up no space until they load, then push content down. Setting the attributes lets the browser reserve the correct aspect ratio even when CSS makes the element responsive.

<img src="/images/chart.webp" width="800" height="450" alt="Monthly traffic chart">

/* CSS keeps it responsive while preserving the ratio */
img { max-width: 100%; height: auto; }

Reserve space for ads, embeds and dynamic content

Ad slots, cookie banners, newsletter bars and embedded widgets that inject themselves into the page are among the worst CLS offenders. Reserve their space in advance with a fixed or minimum height, and avoid inserting new content above existing content unless it is in response to a user action.

.ad-slot {
  min-height: 250px;   /* reserve the most common ad size */
}
.embed-wrapper {
  aspect-ratio: 16 / 9;
}

Control web font swaps

When a web font loads and replaces a fallback font with different metrics, text reflows and shifts. Options include font-display: optional (which avoids the swap if the font is not ready quickly), preloading critical fonts, and adjusting fallback font metrics with size-adjust and related descriptors so the swap barely moves anything.

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-display: swap;
}
@font-face {
  font-family: "Brand Sans Fallback";
  src: local("Arial");
  size-adjust: 104%;
}

Prefer transform-based animations

Animating properties such as top, height or margin triggers layout and can create shifts. Animate transform and opacity instead. Also make pages eligible for the back/forward cache, which lets returning visitors see an instant, stable page.

How much Core Web Vitals matter for rankings

Google has confirmed that Core Web Vitals are used by its ranking systems as part of a broader set of page experience considerations. It has also been clear that good page experience does not override relevance. Its page experience documentation emphasizes that Google seeks to reward content with a good page experience, but that great scores alone do not guarantee top rankings.

In practice, that means:

• Moving from "poor" to "good" can help, particularly when competing pages are similarly relevant and useful.
• Chasing tiny improvements on already-good metrics is unlikely to change rankings noticeably.
• A slow page with the best answer will often outrank a fast page with a weak one.

The strongest case for Core Web Vitals is often not rankings at all. Faster, more stable pages tend to be easier and more pleasant to use, which supports engagement and conversions. Treat performance as a product quality issue that also has SEO benefits, not as an SEO trick.

A practical workflow and ongoing monitoring

Performance work goes best as a repeatable process rather than a one-time sprint. This is the workflow we use in a technical SEO audit.

1. Find the patterns. Start with the Search Console report to see which URL groups fail on which device type.
2. Pick representative URLs. Choose one or two high-traffic pages per failing template.
3. Diagnose in the field and lab. Check PageSpeed Insights, then reproduce the issue in Chrome DevTools with CPU and network throttling.
4. Fix at the template level. Fixing a shared component fixes every page that uses it.
5. Validate and wait. Deploy, confirm lab improvements, then use Search Console's validation feature. Allow the 28-day CrUX window to catch up.
6. Guard against regressions. Add performance budgets or Lighthouse checks to your deployment process, and review new third-party scripts before they go live.

Performance also interacts with content decisions. Heavy embeds, oversized images and autoplaying media are often editorial choices, so share guidelines with the people who publish content, not just with developers. Our guide to content marketing with topic clusters covers how to build those standards into an editorial workflow.

Next steps

Core Web Vitals reward a simple discipline: deliver the main content quickly, keep the main thread free for the user, and do not move things around unexpectedly. Start with your Search Console report, fix the worst template first, and build monitoring so the gains stick.

If you want a clear, prioritized plan for your site's performance and technical health, our technical SEO audit service includes a full Core Web Vitals review. You can also try the checks on our SEO tools page, or contact us to discuss your site.