Core Web Vitals are three measurements Google uses to judge the real-world experience of a web page: 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 real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less. These are measured separately for mobile and desktop.

You do not need to become a developer to use these numbers. You need to know what each one means, where the data comes from, and which problems are worth paying to fix.

Why should a business owner care about Core Web Vitals?

Because they describe what your customers actually feel when they use your site: waiting, tapping and losing their place. Google also uses them as part of its page experience signals in search.

It is worth keeping this in proportion. Google has been clear that great page experience does not override relevant, helpful content. A fast page with weak content will not outrank a useful page that is slightly slower. But when competing pages are similarly useful, experience can matter, and a slow, jumpy site loses enquiries regardless of rankings. Someone checking your product range on a phone between meetings will not wait patiently.

The three metrics in plain English

MetricWhat it measuresGoodNeeds improvementPoor
LCP (Largest Contentful Paint)Time until the main content, usually a hero image or headline, appears≤ 2.5 s2.5–4 sOver 4 s
INP (Interaction to Next Paint)How quickly the page visibly responds to taps, clicks and key presses≤ 200 ms200–500 msOver 500 ms
CLS (Cumulative Layout Shift)How much content unexpectedly moves while the page is in use≤ 0.10.1–0.25Over 0.25

LCP: does the important part load quickly?

LCP marks the moment the largest visible element in the first screen finishes rendering. On most business websites that is a banner image, a product photo or a large heading. If your homepage hero is a heavy, uncompressed image served from slow hosting, LCP suffers.

INP: does the page react when I tap?

INP looks at the delay between a user interaction and the next visual update, across the visits it observes, and reports a value close to the worst one. If someone taps “Menu” or “Add to cart” and nothing happens for a moment, that is poor INP. The usual cause is too much JavaScript running in the browser, often from chat widgets, tracking scripts, sliders and page builders.

CLS: does the page stay still?

CLS measures layout jumps. You have experienced it when you go to tap a link and a late-loading banner pushes everything down, so you tap an ad instead. Images without set dimensions, late-loading fonts, cookie bars and injected ads are common culprits.

What happened to FID?

First Input Delay (FID) was the original responsiveness metric. In March 2024, Google replaced it with INP as a Core Web Vital.

FID only measured the delay before the browser started handling the very first interaction. INP is stricter: it considers interactions throughout the visit and includes the time until the screen actually updates. Some sites that comfortably passed FID found they had INP problems, especially those relying heavily on JavaScript. If an older audit report mentions FID, it predates this change.

Field data vs lab data: which numbers count?

Field data comes from real users and is what Google assesses; lab data comes from a simulated test and is what developers use to diagnose problems. You need both, but for different jobs.

  • Field data is collected from real Chrome users who have opted in, and published in the Chrome User Experience Report (CrUX). It reflects real devices, real networks and real behavior, aggregated over a rolling 28-day window. This is the data behind the Core Web Vitals assessment.
  • Lab data comes from Lighthouse running a single, controlled test on a simulated device and connection. It is repeatable and great for spotting causes, but it is one scenario, not your audience.

Lab tests cannot measure INP directly because nobody is tapping the page. Lighthouse reports Total Blocking Time (TBT) as a lab indicator of the same kind of problem.

Smaller or newer sites may not have enough traffic to appear in CrUX. In that case you will see only lab data, and you should treat it as a guide rather than a verdict.

How to read your PageSpeed Insights report

PageSpeed Insights shows field data at the top and lab data below it. Read them in that order.

  1. Enter your URL and check the mobile tab first. Mobile usually has the harder conditions.
  2. Look at the field assessment. It says whether this URL, or the whole origin if there is not enough URL-level data, passes Core Web Vitals.
  3. Note which metric fails. One failing metric is a focused fix; three failing metrics suggests a structural problem with the theme or hosting.
  4. Use the diagnostics in the lab section to understand why: oversized images, render-blocking resources, unused JavaScript and so on.
  5. Check Google Search Console’s Core Web Vitals report to see which groups of similar pages are affected across the whole site.

Do not chase a perfect lab score of 100. It is a diagnostic aid, not a goal. Passing field metrics and a site that feels quick are what matter.

What usually fixes each metric?

Improving LCP

  • Compress and correctly size hero images; use modern formats such as WebP or AVIF.
  • Do not lazy-load the main above-the-fold image; prioritize it instead.
  • Improve server response time with better hosting and page caching; on WordPress, WordPress speed optimization often starts here.
  • Reduce render-blocking CSS and fonts.

Improving INP

  • Audit third-party scripts and remove the ones nobody uses.
  • Delay non-essential scripts such as chat widgets until after interaction.
  • Replace heavy page-builder elements and sliders with lighter components.
  • Break up long JavaScript tasks so the browser can respond in between.

Improving CLS

  • Set width and height on images, videos and embeds.
  • Reserve space for banners, ads and cookie notices.
  • Load web fonts in a way that avoids large reflows.

For a hypothetical Ahmedabad textile exporter whose catalogue pages fail LCP on mobile, the fix might be as unglamorous as resizing product photos that were uploaded straight from a camera. Not every improvement needs a rebuild.

Key takeaways

  • LCP, INP and CLS measure loading, responsiveness and visual stability.
  • Good means LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1 at the 75th percentile of real visits.
  • INP replaced FID in March 2024 and is a stricter test of responsiveness.
  • Field data from CrUX is what Google assesses; lab data helps diagnose causes.
  • Content quality still comes first, but a slow or jumpy site costs enquiries either way.

Next steps

Run your three most important pages through PageSpeed Insights on mobile and note which metric fails. If the causes point to theme, hosting or script problems, a technical SEO review can prioritize the fixes that matter most for your site.