Core Web Vitals are a set of metrics that describe key parts of the experience a real visitor has on a web page: how quickly the main content appears, how promptly the page responds to an interaction and whether the layout remains visually stable while it loads.

The three current metrics are LCP (Largest Contentful Paint), INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift). They do not provide a complete verdict on a website, but they reveal friction that can affect usability, trust, conversions and technical SEO.

This guide explains what each metric measures, how Google evaluates it and how to improve it methodically. The goal is not a perfect score for its own sake. It is a faster, more stable and more responsive experience for real users.

What Core Web Vitals Are

Core Web Vitals are user-centred performance metrics. Unlike a generic loading-time figure, each metric focuses on a distinct moment in the visit:

  • LCP: when the largest visible content element finishes rendering.
  • INP: how quickly the page provides visual feedback after a user interaction.
  • CLS: how much visible content moves unexpectedly during the page's lifetime.

They should be read together. A page may load its hero quickly but still feel sluggish after a click. Another may respond quickly but shift buttons and text while assets load. Good performance means controlling all three aspects without compromising content or functionality.

Why They Matter

Performance affects the way people experience a website before they assess its copy or design. A slow main element delays understanding. An unresponsive interface makes the page feel broken. Unexpected layout movement can cause a visitor to tap the wrong control.

These problems are particularly important on mobile devices, where processing power, connection quality and viewport space vary widely. Improving them can reduce friction in navigation, forms and commercial landing pages.

Core Web Vitals are also part of Google's page-experience signals. They do not replace relevance, content quality, internal structure or authority, and passing them does not guarantee rankings. They support the technical quality of a page and remove obstacles that can weaken an otherwise strong result.

Practical principle: optimize the pages that matter to users and the business, not just the page that is easiest to make green in a testing tool.

How Google Evaluates Them

Google primarily evaluates Core Web Vitals using anonymized field data from real Chrome users. Results are grouped by page or, when there is not enough URL-level data, by similar URLs. The assessment uses the 75th percentile so that a page must provide an acceptable experience to most visits, not only to users on fast devices.

MetricGoodNeeds improvementPoor
LCPUp to 2.5 secondsOver 2.5 and up to 4 secondsOver 4 seconds
INPUp to 200 msOver 200 and up to 500 msOver 500 ms
CLSUp to 0.1Over 0.1 and up to 0.25Over 0.25

A URL passes the Core Web Vitals assessment only when all three metrics are in the good range. Because field data covers a rolling period, improvements made today will not appear immediately in every Google report.

How to Measure Them Correctly

Field data from real users

Field data describes actual visits across different devices, networks and locations. Review it in Google Search Console's Core Web Vitals report and in tools that expose Chrome UX Report data. It is the right source for understanding whether a problem affects real users at scale.

Lab data for testing and debugging

Lab tools such as Lighthouse and PageSpeed Insights run a repeatable test under controlled conditions. They are valuable for diagnosing render-blocking resources, long JavaScript tasks, oversized images and layout shifts, but one lab run is not representative of every visit.

Use both: field data to identify the real problem and lab data to investigate likely causes. Test representative templates, not just the homepage, and repeat measurements after clearing caches or changing infrastructure.

LCP (Largest Contentful Paint)

LCP measures when the largest image or text block visible in the viewport finishes rendering. It is intended to approximate the point at which the main content feels available.

What is commonly measured as the LCP element

Typical candidates include a hero image, a large heading, a poster image or a prominent content block above the fold. The exact element can change between desktop and mobile.

Common causes

  • slow server response and uncached dynamic pages;
  • large or incorrectly sized hero images;
  • render-blocking CSS, JavaScript or web fonts;
  • the LCP asset being discovered late through CSS or JavaScript;
  • too much above-the-fold complexity.

What to do in practice

CauseUseful action
Slow server responseImprove page caching, database work, hosting resources and CDN delivery.
Heavy hero assetServe an appropriately sized AVIF or WebP image and compress it without visible degradation.
Late asset discoveryKeep the important image in the initial HTML and preload it only when it is genuinely the LCP resource.
Blocking resourcesUse critical CSS and defer for scripts that are not required for initial rendering.

Safe examples

Do not preload every image or script. Excessive preloading competes for bandwidth and can make LCP worse.

INP (Interaction to Next Paint)

INP evaluates responsiveness by observing interactions such as clicks, taps and keyboard input, then measuring how long the browser takes to present the next visual update. It reflects the page's overall interaction experience rather than a single first interaction.

What has the greatest effect on INP

  • long JavaScript tasks that block the main thread;
  • large DOM updates after an interaction;
  • heavy third-party scripts, widgets and tracking tags;
  • event handlers that perform too much synchronous work;
  • complex rendering and repeated layout calculations.

What to do in practice

Remove unused JavaScript, split large bundles, delay non-essential third-party code and break expensive work into smaller tasks. Keep event handlers focused on immediate feedback and move secondary processing out of the critical interaction path.

Example: splitting work into chunks

function processInChunks(items, chunkSize = 50) {
  const queue = [...items];
  function run() {
    queue.splice(0, chunkSize).forEach(processItem);
    if (queue.length) setTimeout(run, 0);
  }
  run();
}

This pattern yields control between chunks so the browser can process user input and render updates. The appropriate implementation depends on the task; the important point is to avoid one uninterrupted block of work.

CLS (Cumulative Layout Shift)

CLS measures unexpected visual movement. A shift is harmful when content changes position without the user initiating that change—for example, when a banner appears above a button just as someone tries to select it.

Common causes

  • images and iframes without width, height or reserved space;
  • ads, consent banners and embeds inserted into an occupied area;
  • web-font swaps that significantly change text dimensions;
  • dynamic components added above existing content;
  • animations that change layout properties.

What to do in practice

CauseUseful action
Images and embedsAdd width/height attributes or a stable aspect-ratio.
Dynamic bannersReserve their final space or show them as overlays without displacing content.
Web fontsUse a compatible fallback and an appropriate font-display strategy.
AnimationsPrefer transforms and opacity instead of properties that trigger layout.

Example: stabilizing media

.media {
  aspect-ratio: 16 / 9;
  width: 100%;
  object-fit: cover;
}

A Quick Checklist Before Major Changes

  • Identify whether the failing data is field data, lab data or both.
  • Confirm which page template and which metric are affected.
  • Find the actual LCP element instead of assuming it is always the hero image.
  • Review long main-thread tasks and third-party scripts before replacing infrastructure.
  • Check image dimensions, embedded content and banners for layout shifts.
  • Measure mobile and desktop separately.
  • Record a baseline so that every change can be evaluated.

A plugin or hosting change may help, but neither is a substitute for diagnosing the bottleneck first. The same symptom can have a different cause on each template.

A Reliable Workflow: Measure, Change, Verify

  1. Measure: group affected URLs and establish field and lab baselines.
  2. Prioritize: start with high-traffic, lead-generating or strategically important templates.
  3. Change one layer at a time: assets, rendering, JavaScript, fonts, server or third-party code.
  4. Test for regressions: verify layout, forms, tracking, consent and responsive behaviour.
  5. Validate: rerun lab tests and monitor field data over the following weeks.

How this connects to technical SEO

Performance improvements should support crawlability, rendering and content access. Removing critical content from the initial HTML to chase a score, breaking analytics or delaying essential consent behaviour is not a successful optimization. Review performance as part of the wider technical SEO system.

If performance problems affect usability, visibility or leads, the next step is a technical assessment based on the actual templates and traffic paths—not a generic score.