What the core web vitals checker checks

Five metrics. Real visitors.

What Chrome users actually experienced on this page and this site over the last 28 days.

Core Web VitalsPasses
  • LCP2.1 s
  • INP160 ms
  • CLS0.04
Chrome users · last 28 days · p75

The three Core Web Vitals

0 pts

Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift at the 75th percentile, rated good, needs improvement or poor against Google's thresholds.

68
Mobile
94
Desktop
PerformanceSEOA11y

Supporting metrics

0 pts

First Contentful Paint and Time to First Byte, the two diagnostics that usually explain a slow LCP.

Internal linksdepth ≤ 3
orphan

Distribution, not just p75

0 pts

The share of visits that were good, needs improvement and poor for every metric, so you see how close you are to passing.

<html lang="en">
<link rel="canonical">
<meta name="description">
<main>
text 18%

Page and origin, mobile and desktop

0 pts

Up to four records: this page and the whole site, each on phones and on desktops, since Google assesses page groups on mobile first.

73
Health score
9 issues · 2 critical
  • Meta tags
  • Headings
  • Images
  • Schema
  • Mobile

Pass or fail verdict

0 pts

A page passes when all three core metrics are good at p75. The verdict is shown for every record found.

author
Updated
HTTPS
/about/contact

Field data from Chrome

0 pts

Real visits over the last 28 days from the Chrome UX Report, the same dataset behind Search Console's Page Experience report.

Why it matters

Lab scores lie. Field data ranks.

Lab tools measure one simulated load. Google ranks on what real Chrome users experienced over the last 28 days. Those two numbers disagree more often than you would think.

01

Field data is what Google uses

The page experience signal and the Search Console report are built from the Chrome UX Report. A green Lighthouse score with poor field data still fails.

Field data from ChromePass or fail verdict
02

p75 is a high bar

A metric is good only if 75% of visits are good. A page that is fast on your laptop can fail because a quarter of visitors are on slow phones.

The three Core Web VitalsDistribution, not just p75
03

Mobile decides

Google assesses mobile and desktop separately and uses mobile for mobile rankings, which is most of them. Fix mobile first.

Page and origin, mobile and desktop
How to improve

Fix the failing metric. Then wait for the 28-day window.

  1. 1

    Start with the failing core metric

    The verdict names it. LCP is usually the hero image or a render-blocking font; INP is heavy JavaScript on tap; CLS is images without dimensions or late-loading banners.

  2. 2

    Cut LCP with the basics

    Preload the hero image, serve it in a modern format at the right size, inline critical CSS and put the page behind a CDN. TTFB under 800 ms makes everything else easier.

  3. 3

    Fix INP by doing less on the main thread

    Break long tasks, defer third-party scripts, and respond to taps before running heavy work. Most INP problems are tag managers and chat widgets.

  4. 4

    Stop layout shift at the source

    Give every image, ad slot and embed explicit width and height, and never inject content above what the user is reading.

  5. 5

    Wait 28 days and re-check

    The Chrome UX Report is a rolling 28-day window. Improvements show up gradually; check weekly until the p75 crosses the good threshold.

Score after fixes
41 → 93
F
D
C
B
A
robots.txt
llms.txt
FAQPage

Get told before Core Web Vitals slip

SiteLift runs technical audits on a schedule, tracks Core Web Vitals and indexability, and flags regressions before they cost rankings.

No credit card required

Frequently Asked Questions

Everything you need to know about the core web vitals checker.

From the Chrome UX Report (CrUX) API, Google's public dataset of real Chrome user experiences over the last 28 days. It is the same data behind the Core Web Vitals report in Search Console.