Core Web Vitals test: how to measure and fix LCP, INP and CLS

What does a Core Web Vitals test measure?

The Core Web Vitals are three user-centred metrics. Each has a “good” threshold, and a tool should only call a page passing when it meets the target at the 75th percentile of page loads, segmented by mobile and desktop, for all three.

INP became a Core Web Vital and replaced First Input Delay on 12 March 2024. Google Search Console dropped FID the same day. Hovering, zooming and scrolling do not count towards INP.

Google’s page experience documentation says Core Web Vitals are used by its ranking systems. It also says that good scores do not guarantee a top ranking and that there is more to page experience than the scores alone. Treat the metrics as a quality bar, not a shortcut.

Lab data or field data: which one should you trust?

Every Core Web Vitals tester falls into one of two groups. Field tools report what real visitors experienced. Lab tools load the page once in a controlled setup. web.dev recommends using field data to prioritise work and lab data to debug and to test changes before release.

The numbers differ for good reasons. A lab run usually starts with a cold cache, while real visits include cached loads. Field LCP stops tracking larger elements once the user interacts. INP depends on real interaction timing, which is why Lighthouse cannot measure it and suggests Total Blocking Time as a proxy.

Field data has its own limits. A page must be publicly discoverable and have enough visitors, and the exact number is not disclosed. Only desktop Chrome and Chrome on Android contribute, as the CrUX methodology explains. Chrome on iOS, Android WebView apps and other Chromium browsers do not.

How do you test Core Web Vitals?

PageSpeed Insights

Enter a URL and PageSpeed Insights shows field data from CrUX for the previous 28-day collection period at the 75th percentile, plus Lighthouse lab data, for mobile and desktop. If a URL has too little data it falls back to the whole origin. The page passes the assessment when the 75th percentile of all three metrics is good. When INP data is missing, LCP and CLS decide.

Google Search Console

The Core Web Vitals report uses CrUX field data, split by mobile and desktop. It groups URLs with a similar experience, and the group’s status is set by its worst metric. Use it to find which page types fail across the site.

Lighthouse and Chrome DevTools

Lighthouse runs in the DevTools Lighthouse tab, from the command line, as a Node module or inside PageSpeed Insights. It is the right tool for finding the LCP element and long tasks and for confirming a fix straight after a deploy.

The CrUX API

The CrUX API returns field data for a URL or an origin and needs an API key. Google documents a limit of 150 queries per minute per project. The 75th percentile is under percentiles.p75 for each metric.

curl -s --request POST "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$CRUX_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{"url":"https://example.com/","formFactor":"PHONE","metrics":["largest_contentful_paint","interaction_to_next_paint","cumulative_layout_shift"]}'

Your own users

The web-vitals library measures the three metrics in your visitors’ browsers, so you see your own audience, including browsers CrUX ignores.

import { onCLS, onINP, onLCP } from 'web-vitals'

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id,
  })
  navigator.sendBeacon('/analytics', body)
}

onCLS(sendToAnalytics)
onINP(sendToAnalytics)
onLCP(sendToAnalytics)

Serpel

With every crawl, Serpel’s site audit asks PageSpeed Insights to measure the home page and a small, fixed number of the most-linked indexable pages, on mobile and desktop. For each URL and device it stores the performance score, the field values for LCP, INP and CLS and the lab values for LCP, CLS, Total Blocking Time, First Contentful Paint and Speed Index.

Findings follow a fixed order. Serpel rates the URL’s field value against the thresholds above, falls back to origin-level field data when the URL has none, and only then uses the lab value for LCP and CLS. It reports the worse of mobile and desktop. If PageSpeed Insights is unreachable or the quota is used up, the crawl still finishes and the audit notes that the vitals could not be measured.

serpel crawl start --project <project-id> --wait
serpel audit web-vitals <crawl-id>

How do you read a PageSpeed Insights report?

Start at the top. The field section answers whether real users have a good experience. It shows the page itself or, when the page has too little data, its whole origin, and it has separate results for mobile and desktop, which can differ a lot. Only these field values decide the Core Web Vitals assessment.

The lab section below is a single Lighthouse run. Its performance score summarises lab metrics and does not decide the assessment. Use the diagnostics for the metric that fails in the field instead of chasing a score of 100.

Which pages should you test first?

Test one URL per page template instead of every URL: the home page, a listing, a detail page, a content page and any checkout or form. Pages of a template share code, so a fix usually carries over. Start with the templates that get the most traffic or that Search Console flags. Test mobile first, because Google primarily indexes the mobile version of most sites.

How do you fix a failing metric?

Start with the metric that fails in field data, then use lab tools to find the cause. web.dev splits LCP into four parts. As a guideline, time to first byte and resource load duration should each take about 40% of the total, while resource load delay and element render delay should each stay under 10%.

<img src="/images/hero.webp" width="1200" height="630" alt="Product dashboard" fetchpriority="high">

If you build with Next.js, the framework handles part of this for images and fonts. The Next.js SEO guide shows the settings.

How long until a fix shows up?

Field data moves slowly because CrUX reports a 28-day window. After you fix a Search Console issue, fix validation monitors the URLs for 28 days. Confirm the change with a lab run on the same day, then watch the field numbers for a month before you call it done.