What are Core Web Vitals?

Core Web Vitals are three user-experience metrics Google measures: Largest Contentful Paint (loading, good at 2.5 seconds or less), Interaction to Next Paint (responsiveness, good at 200 milliseconds or less) and Cumulative Layout Shift (visual stability, good at 0.1 or less). A page passes when the 75th percentile of real visits meets all three.

Last updated 2026-07-28

What are the three Core Web Vitals and their exact thresholds?

The three Core Web Vitals are Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. Those are the "good" thresholds; each metric also has a middle band and a poor band, and a page has to clear the good threshold on all three to be counted as passing.

The thresholds are not round numbers picked for tidiness. Google's stated criteria for setting one include that it represent a genuinely good experience for users and that a meaningful share of sites already achieve it, so passing has to be demonstrably possible on ordinary hardware rather than only on a developer's laptop.

Why does Google use the 75th percentile rather than an average?

Because an average hides the slowest quarter of your visitors, and that quarter is exactly the group that gives up and leaves. Assessment therefore takes the 75th percentile of real visits over a rolling 28-day window, segmented separately for mobile and desktop — in plain terms, three quarters of your visitors must have a good experience before the page counts as passing.

This is also why lab tools and field data disagree so often. A single run on a fast Mac over fibre is one sample under ideal conditions; the 75th percentile of real traffic includes mid-range Android phones on congested mobile networks, which is a different page entirely.

The 28-day window has a practical consequence: a fix you ship today will not be fully visible in Search Console for about a month, because the window still contains three and a half weeks of the old experience.

What is the difference between lab data and field data?

Lab data is a single simulated page load you trigger yourself; field data is what real visitors actually experienced, gathered by Chrome and published in the Chrome User Experience Report. Only field data counts towards the official Core Web Vitals assessment — lab data exists to tell you why.

Field data takes 28 days to move and only exists for pages with enough traffic to be reported. Lab data — from Google Lighthouse, PageSpeed Insights or Audra — is instant, reproducible and available for any page at all, including staging and pre-launch builds that no real user has ever loaded.

Use lab data to find and fix causes, then confirm the fix in field data. Chasing a lab score without ever checking the field result is the most common way to spend a week on something your users never notice.

What happened to First Input Delay?

Interaction to Next Paint replaced First Input Delay as the responsiveness Core Web Vital in March 2024, and FID was retired from Google's tooling later that year. If a guide still lists FID as a Core Web Vital, it predates that change.

INP is deliberately stricter. FID measured only the delay before the browser began processing the first interaction, so a page could score well while every click after the first took a second to do anything visible. INP measures the full latency of interactions across the whole visit — from the input through event handling to the next frame being painted — which is far closer to what a person actually perceives as lag.

The practical difference is where you look for the problem. FID pushed you towards trimming startup JavaScript; INP pushes you towards long event handlers, expensive re-renders and heavy work triggered by clicks and keystrokes well after load.

Do Core Web Vitals actually affect Google rankings?

Yes, but weakly — they act as a tiebreaker between pages of comparable relevance, not as a substitute for relevance. No amount of performance work will float a page that does not answer the query.

Their larger effect is downstream of ranking. Slow, jumpy pages get abandoned before they are read, so the same page can rank identically and convert far worse. If you need a business case for the work, measure bounce and conversion rather than position.

How do you check Core Web Vitals across a whole site?

Run a lab audit on every page rather than the handful you happen to remember, because Core Web Vitals problems are usually template problems. One slow hero image in a blog template affects every post, and you cannot see that pattern from a single-URL test.

Search Console groups URLs by field data and is the authority on whether you pass, but it only covers pages with enough traffic and tells you little about the cause. PageSpeed Insights gives you both lab and field figures for one URL at a time. A crawler that runs Lighthouse per page gives you the third view: the same lab metric across hundreds of URLs, where repetition is the signal.

Audra takes that third approach. It runs Google Lighthouse, axe-core accessibility checks, broken-link checking and its own HTML SEO and answer-engine checks over every crawled page — 100 pages by default, configurable, with include and exclude path globs — and rolls the results into one Audra Score weighted performance 30%, SEO 30%, accessibility 25%, best practices 15%. It is a macOS (Apple Silicon) and Windows (64-bit) app that drives your own installed copy of Chrome, so nothing leaves the machine and it can audit staging and password-protected sites that PageSpeed Insights cannot reach. It is $19 once with a free 7-day trial, no subscription.

Start with the metric that is failing: Largest Contentful Paint if the page is slow to appear, Cumulative Layout Shift if it jumps around while loading.