Bots verified with official IP lists
GoogleBingChatGPTClaudePerplexityAppleDuckDuckGo
Search engines we optimise for
GoogleBingBrave
← Guides

Core Web Vitals in plain words: LCP, INP and CLS

What LCP, INP and CLS measure, the “good” thresholds, field vs lab data in PageSpeed Insights, and the common fixes that make pages feel faster.

Updated 25 October 2026 · 4 min read

Core Web Vitals in plain words: LCP, INP and CLS

Core Web Vitals are three measurements Google uses to describe how a page feels to real visitors: how fast the main content appears (LCP), how quickly the page responds to taps and clicks (INP), and how much the layout jumps around (CLS). A page passes when 75% of visits meet the “good” threshold for all three.

The three metrics

LCP: Largest Contentful Paint

LCP measures how long it takes for the biggest visible element, usually a hero image, a video poster or a large block of text, to appear on screen. It’s a stand-in for “when does the page look loaded?”

INP: Interaction to Next Paint

INP measures how long the page takes to visibly respond after a visitor clicks, taps or presses a key. It looks at interactions throughout the visit and reports one of the slowest. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, because FID only measured the first interaction and missed slow pages that felt sluggish later.

CLS: Cumulative Layout Shift

CLS measures unexpected movement: text that jumps down when an image loads, or a button that moves just as you go to tap it. It’s a score without units, not a time.

The thresholds

MetricGoodNeeds improvementPoor
LCP≤ 2.5 s2.5–4 s> 4 s
INP≤ 200 ms200–500 ms> 500 ms
CLS≤ 0.10.1–0.25> 0.25

Google judges each metric at the 75th percentile of real visits, split by mobile and desktop. In other words, three out of four visits need to be “good” for the page to count as good. This stops a few fast visits on office broadband from hiding a slow experience on phones.

Field data vs lab data

This is the part that confuses most people.

  • Field data comes from real Chrome users who visited your page, collected in the Chrome User Experience Report (CrUX). It covers the last 28 days. This is what Google uses when it assesses Core Web Vitals.
  • Lab data comes from a single simulated test (Lighthouse) on a set device and connection. It’s useful for finding causes and testing fixes, but it’s not what real visitors experienced.

The two often disagree, and that’s expected. A lab test runs one page load in fixed conditions; field data mixes thousands of visitors on different phones and networks.

Lab tests can’t measure INP directly, because nobody is clicking. Lighthouse reports Total Blocking Time instead, which is a rough hint about how busy the page keeps the browser.

Small or new sites often have no field data, because there isn’t enough Chrome traffic to report. In that case, use lab data as a guide and focus on the fixes below.

Using PageSpeed Insights

  1. Go to PageSpeed Insights and enter a URL.
  2. Check the Mobile tab first; it’s usually the harder one.
  3. Read the top section, “Discover what your real users are experiencing”. That’s field data. If it shows data for the URL, use that; otherwise it may show data for the whole origin.
  4. Scroll down to the Lighthouse diagnostics for specific causes, such as large images or long JavaScript tasks.

Test page templates, not just the home page: one article, one product, one category. Fixing a template fixes every page built on it. OZMAICO’s Page speed tool runs PageSpeed Insights for your pages and shows the Core Web Vitals results in one place.

Google Search Console also has a Core Web Vitals report that groups similar URLs by status, using the same field data.

Common fixes

Improving LCP

  • Serve a properly sized, compressed image (WebP or AVIF) for the hero, not a 4000-pixel original.
  • Don’t lazy-load the main image. Lazy loading is great below the fold, but it delays the LCP image.
  • Speed up the server response. Caching and a CDN help most.
  • Cut render-blocking CSS and JavaScript in the <head>, and load web fonts efficiently.

Improving INP

  • Load less JavaScript, especially third-party scripts such as chat widgets, ad tags and trackers.
  • Break up long tasks so the browser can respond between them.
  • Keep event handlers light. Show visual feedback first, do heavy work afterwards.
  • Avoid huge, deeply nested pages that are slow to update.

Improving CLS

  • Set width and height (or an aspect ratio) on images, videos and iframes, so space is reserved.
  • Reserve space for ads and embeds before they load.
  • Don’t insert banners above existing content after the page appears.
  • Use font-display sensibly and similar fallback fonts so text doesn’t reflow badly.

How much do they matter for SEO?

Core Web Vitals are part of Google’s page experience signals, and Google has said it uses them in ranking. It has also said that relevant, helpful content matters more, so a fast page with weak content won’t outrank a slower, much better one. Treat good Core Web Vitals as a tie-breaker and, more importantly, as a better experience for visitors. Speed is one part of a wider technical SEO audit.

In short

  • LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1, at the 75th percentile.
  • Field data is what counts; lab data helps you find causes.
  • Test templates on mobile first, in PageSpeed Insights.
  • Fix big images and slow servers for LCP, heavy JavaScript for INP, and missing dimensions for CLS.
  • Re-check field data about four weeks after a fix, as it covers a rolling 28 days.

Check your own website

See which AI bots really visit your site — real or fake, page by page — and how many people AI assistants send you. Free.

Contact us