LocalSEOTrack
Home/ Resources/ Core Web Vitals: What They Are & How to Improve Them

Core Web Vitals: What They Are & How to Improve Them

Published March 4, 2026

Core Web Vitals: What They Are & How to Improve Them

Core Web Vitals are a set of three specific page experience metrics that Google uses to measure how users experience the speed, responsiveness, and visual stability of a web page. Introduced as a ranking signal in 2021, these metrics — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — directly influence your search rankings and represent the minimum performance standards every website should meet.

What Are the Three Core Web Vitals?

Each Core Web Vital measures a distinct aspect of the user experience. Together, they cover the full lifecycle of a page interaction: loading, interactivity, and visual stability.

Largest Contentful Paint (LCP) measures loading performance. It reports the render time of the largest image, video, or text block visible within the viewport. LCP reflects how quickly users see the main content of your page. Common LCP elements include hero images, heading text blocks, and above-the-fold video posters.

Interaction to Next Paint (INP) measures responsiveness. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. While FID only measured the delay of the first interaction, INP observes the latency of all interactions throughout the page lifecycle — clicks, taps, and keyboard inputs — and reports a value representative of the overall responsiveness. This makes INP a far more accurate reflection of how responsive your page feels to users.

Cumulative Layout Shift (CLS) measures visual stability. It quantifies how much the page content shifts unexpectedly during loading. Every time a visible element moves from its rendered position without user input, that shift is counted. CLS is especially frustrating when users try to click a button and the page shifts, causing a misclick.

Core Web Vitals Thresholds

Google classifies each metric into three ranges. To pass Core Web Vitals assessment, your page must meet the "Good" threshold for all three metrics at the 75th percentile of page loads:

Metric          | Good          | Needs Improvement | Poor
----------------|---------------|-------------------|----------
LCP             | ≤ 2.5 seconds | 2.5s – 4.0s       | > 4.0s
INP             | ≤ 200ms       | 200ms – 500ms     | > 500ms
CLS             | ≤ 0.1         | 0.1 – 0.25        | > 0.25

The 75th percentile means that 75% of your page visits must meet the threshold — not just the average or median. This prevents a few fast loads from masking a poor experience for the majority of users.

How to Measure Core Web Vitals

You can measure Core Web Vitals using both lab tools (simulated conditions) and field tools (real user data):

  • Google PageSpeed Insights — Combines lab data from Lighthouse with field data from the Chrome User Experience Report (CrUX). Enter any URL to get scores for all three metrics.
  • Google Search Console — The Core Web Vitals report shows site-wide performance grouped by status (Good, Needs Improvement, Poor) and identifies specific URL patterns that need attention.
  • Chrome DevTools Performance panel — Record a page interaction to see exactly where time is spent. The Performance Insights panel provides Core Web Vitals annotations directly on the timeline.
  • Web Vitals Chrome Extension — Displays LCP, INP, and CLS in real time as you browse your site, making it easy to spot issues during development.
  • Lighthouse CI — Automate performance testing in your CI/CD pipeline to catch regressions before they reach production.
Important: Lab data (Lighthouse, DevTools) simulates a mid-tier mobile device on a throttled connection. Field data (CrUX, Search Console) reflects actual user experiences. Always prioritize field data for SEO decisions — it is what Google uses for ranking.

How to Improve Largest Contentful Paint (LCP)

LCP failures are usually caused by slow server responses, render-blocking resources, slow resource load times, or client-side rendering delays. Target each one:

  1. Optimize your server response time — Aim for a Time to First Byte (TTFB) under 800ms. Use a CDN, enable caching, and optimize database queries. Server response time is the foundation — everything else waits for it.
  2. Remove render-blocking resources — Inline critical CSS directly in the <head> and defer non-critical stylesheets. Use the defer or async attribute on JavaScript files that do not affect above-the-fold content. Minify your CSS with the CSS Minifier and JavaScript with the JS Minifier to reduce file sizes.
  3. Optimize your LCP resource — If the LCP element is an image, compress it, serve it in WebP or AVIF format, and add a <link rel="preload"> tag so the browser fetches it early. Set explicit width and height attributes.
  4. Avoid lazy loading the LCP image — The loading="lazy" attribute delays the load of the image until it is near the viewport. Your LCP image is already in the viewport on load, so lazy loading it actively hurts performance.
  5. Minimize HTML document size — Large HTML documents take longer to parse. Run your markup through the HTML Minifier and remove unnecessary inline styles and scripts.

How to Improve Interaction to Next Paint (INP)

INP measures the time from when a user interacts with the page to when the browser paints the next frame reflecting that interaction. Poor INP is almost always caused by heavy JavaScript execution blocking the main thread.

  1. Reduce total JavaScript — Audit your bundles and remove unused code. Every kilobyte of JavaScript must be downloaded, parsed, compiled, and executed. Less JavaScript means faster interactions.
  2. Break up long tasks — Any task that blocks the main thread for more than 50ms is a "long task." Use requestIdleCallback(), setTimeout(), or the scheduler.yield() API to break long-running functions into smaller chunks that yield to the browser between iterations.
  3. Optimize event handlers — Move heavy computation out of click, input, and scroll handlers. Debounce frequent events and avoid forced synchronous layouts (reading layout properties immediately after writing them).
  4. Reduce DOM size — Pages with more than 1,400 DOM elements experience measurably slower interactions. Simplify your HTML structure and avoid deeply nested elements.
  5. Defer non-critical third-party scripts — Analytics, chat widgets, and ad scripts can add hundreds of milliseconds to interaction latency. Load them after the page is interactive.
Tip: Use Chrome DevTools > Performance panel to record user interactions. Look for long tasks (marked with red triangles) in the flame chart and trace them back to specific functions. The "Interactions" track shows exactly which interactions had poor INP scores.

How to Improve Cumulative Layout Shift (CLS)

Layout shifts happen when visible elements move after they have been rendered. The fix is almost always about reserving space for content before it loads:

  1. Always set dimensions on images and embeds — Add explicit width and height attributes (or use CSS aspect-ratio) on every <img>, <video>, <iframe>, and ad slot. This lets the browser reserve the correct space before the resource loads.
  2. Avoid inserting content above existing content — Banners, cookie notices, and dynamically injected elements that push content down are the most common CLS offenders. If you must insert content, use transform animations or reserve space with a placeholder.
  3. Use font-display: swap carefully — While swap prevents invisible text, the font swap itself can cause layout shifts if the fallback and web font have different metrics. Use the CSS size-adjust, ascent-override, and descent-override descriptors to match fallback font metrics to your web font.
  4. Avoid CSS that triggers layout recalculation — Properties like top, left, width, and height trigger layout. Prefer transform for animations, which runs on the compositor thread without causing shifts.
  5. Contain dynamic content — Use min-height on containers that will receive dynamically loaded content (product listings, feed items) so the page structure remains stable as content streams in.

How Core Web Vitals Impact SEO Rankings

Core Web Vitals became a Google ranking signal in June 2021 as part of the Page Experience update. Here is how they factor into rankings:

  • Tiebreaker signal — When two pages have similar content relevance, the page with better Core Web Vitals scores gets the ranking advantage. Content quality still dominates, but performance breaks ties.
  • Top Stories eligibility — Pages must pass Core Web Vitals to appear in Google's Top Stories carousel on mobile.
  • Indirect ranking benefits — Fast, stable pages reduce bounce rates and increase time on site, which are engagement signals that influence rankings independently of Core Web Vitals.
  • Search Console visibility — Pages failing Core Web Vitals are flagged in Search Console, and Google communicates that these pages may have reduced visibility in search results.

While Core Web Vitals alone will not catapult a thin-content page to position one, they are an increasingly important part of a comprehensive SEO strategy — especially in competitive niches where multiple high-quality pages compete for the same queries.

Related Tools

CSS Minifier JavaScript Minifier HTML Minifier

Start by measuring your current Core Web Vitals scores in Google Search Console, fix the highest-impact issues first, and re-measure. For a deeper dive into CSS performance specifically, read the CSS Optimization Guide, and for a broader set of speed techniques, see Website Speed Optimization.