Core Web Vitals are three metrics Google uses to describe real-user page experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. A page passes when, at the 75th percentile of visits, LCP is 2.5 s or less, INP is 200 ms or less and CLS is 0.1 or less. Below you will find what each metric means, where to see your scores and the fixes that usually move them.

The three metrics and their thresholds

Metric What it measures Good Needs improvement Poor
LCP Time until the largest image or text block in the viewport renders 2.5 s or less 2.5 s to 4 s Over 4 s
INP Delay between a user interaction (tap, click, key press) and the next visual update, across the visit 200 ms or less 200 ms to 500 ms Over 500 ms
CLS How much visible content moves unexpectedly while the page is open 0.1 or less 0.1 to 0.25 Over 0.25

Two points matter for reading these numbers:

  • The 75th percentile. Your score is the value that 75% of visits meet or beat. A fast experience on your office Wi-Fi does not count if many visitors use slower phones on mobile data.
  • INP replaced FID on 12 March 2024. First Input Delay only measured the first interaction. INP looks at interactions throughout the visit and reports a value close to the slowest one, so heavy JavaScript that runs after load now shows up.

Field data and lab data

Field data comes from real Chrome users through the Chrome UX Report (CrUX). This is what Google's Core Web Vitals assessment uses. It covers a rolling 28-day window, so a fix takes weeks to show fully. Low-traffic pages may have no field data at all.

Lab data comes from a tool such as Lighthouse loading your page on a simulated device and network. It is repeatable and good for debugging, but it is not what real users experience. Lab tests cannot measure INP directly because there is no real user interacting, so Lighthouse reports Total Blocking Time as a related signal.

Use field data to decide what to fix and lab data to find out why.

Where to check your Core Web Vitals

  1. Search Console Core Web Vitals report. Shows groups of similar URLs as Good, Needs improvement or Poor, separately for mobile and desktop. Start here because it covers your whole site.
  2. PageSpeed Insights. Shows field data for one URL (or the whole origin when the URL lacks data) plus a Lighthouse lab test with specific diagnostics, such as which element is the LCP element.
  3. Chrome DevTools. The Performance panel shows live LCP, INP and CLS as you load and use the page.

What the Codesala Page Speed tool measures

The Codesala Page Speed Analyzer measures server response, load time, page weight and request counts for one URL. It does not measure Core Web Vitals. It is still useful for LCP work, because a slow server or a heavy page delays everything that follows. You can also inspect your HTTP response headers to confirm compression and caching headers are in place.

How to fix LCP

The LCP element is usually a hero image, a banner or a large heading. Common causes of a slow LCP:

  • Slow server response.
  • The LCP image is lazy-loaded, discovered late or too large.
  • Render-blocking CSS and fonts.

Load the hero image early, give it dimensions and never lazy-load it:

<img src="/images/hero-1200.webp"
     srcset="/images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
     sizes="100vw"
     width="1200" height="600"
     alt="Handmade diyas on a wooden table"
     fetchpriority="high">

If the hero is a CSS background image, the browser finds it late. Preload it:

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

For web fonts, use font-display so text renders with a fallback font instead of staying invisible:

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-display: swap;
}

Also convert large images to WebP or AVIF, enable page caching on your server or CMS, and use a CDN if your visitors are far from your server (for example, a UK-hosted site with most buyers in India).

How to fix INP

INP gets worse when the main thread is busy with JavaScript at the moment a user taps or clicks. Common causes:

  • Third-party scripts: chat widgets, tag managers, ad and tracking scripts.
  • Long tasks from large frameworks or page builders.
  • Event handlers that do heavy work before updating the screen.

Defer scripts that are not needed for the first render:

<script src="/js/reviews-widget.js" defer></script>

Load a chat widget only when someone asks for it:

const chatButton = document.getElementById("chat-button");
chatButton.addEventListener("click", () => {
  const s = document.createElement("script");
  s.src = "https://chat.example.com/widget.js";
  document.body.appendChild(s);
}, { once: true });

Break long work into smaller chunks so the browser can respond between them:

function yieldToMain() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function processRows(rows) {
  for (const row of rows) {
    renderRow(row);
    await yieldToMain();
  }
}

In event handlers, update the screen first (show a spinner or the selected state), then run the slower work. Remove plugins and tags you no longer use.

How to fix CLS

Layout shifts happen when content appears or resizes after the page has started rendering. Common causes:

  • Images and videos without width and height.
  • Ads, embeds and banners injected above existing content.
  • Web fonts that swap in with different sizes.
  • Animations that change top, left, width or height.

Always set dimensions on images, or use aspect-ratio for responsive embeds:

img { max-width: 100%; height: auto; }
.video-embed { width: 100%; aspect-ratio: 16 / 9; }
.ad-slot { min-height: 250px; }

Reserve space for ad slots and promo bars before they load, as with .ad-slot above. Show cookie banners as an overlay at the bottom of the screen instead of pushing the page down. Animate with transform and opacity, which do not trigger layout:

.menu-panel { transform: translateX(100%); transition: transform 0.2s; }
.menu-panel.open { transform: translateX(0); }

If a font swap causes text to jump, try font-display: optional or choose a fallback font with similar metrics.

A simple Core Web Vitals workflow

Fix template by template, not page by page. One change to a product template can fix thousands of URLs.

  1. Open the Search Console report and pick the largest group of Poor URLs on mobile.
  2. Test one example URL in PageSpeed Insights and note the LCP element, long tasks and shifting elements.
  3. Check server response and page weight with the Page Speed Analyzer, and check the mobile viewport setup.
  4. Apply the fixes above in a staging copy, test again in the lab, then deploy.
  5. Start validation for the issue in the Search Console report and wait for the 28-day field data to update.

Core Web Vitals are one part of a wider site review. Our SEO audit checklist covers the rest, and you can run a free SEO audit on any URL to find on-page issues alongside performance work.

Next steps

  1. Open the Search Console Core Web Vitals report and note which metric fails most on mobile.
  2. Fix LCP first on your highest-traffic template: hero image priority, dimensions and server caching.
  3. Defer or remove third-party scripts to improve INP.
  4. Add dimensions and reserved space to stop layout shifts.
  5. Recheck field data after 28 days.