Core Web Vitals checker
Free for 3 URLs.
Enter a URL to see how it scores on Google's Core Web Vitals. The checker pulls real-user field data from the Chrome UX Report when it exists, runs a fresh Lighthouse lab test through the PageSpeed Insights API, and shows each metric against Google's thresholds for mobile and desktop.
The three metrics
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the main content appears | 2.5 s or less | 2.5 to 4.0 s | Over 4.0 s |
| Interaction to Next Paint (INP) | Responsiveness: delay after taps, clicks and key presses | 200 ms or less | 200 to 500 ms | Over 500 ms |
| Cumulative Layout Shift (CLS) | Visual stability: how much content jumps around | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Google evaluates these at the 75th percentile of page loads. That means a page passes LCP if at least three in four visits load the main content within 2.5 seconds.
INP replaced First Input Delay as a Core Web Vital in March 2024.
Field data versus lab data
Field data (top of the results) comes from real Chrome users who opted in to share usage statistics. It covers the previous 28 days. It is the data Google uses when assessing page experience. If a page does not get enough traffic, you will see origin-level data for the whole site instead, or a message that no field data exists.
Lab data (below) comes from a single Lighthouse test run on a simulated device and network. It is useful for debugging because it is repeatable and reacts instantly to changes. It cannot measure INP because nobody interacts with the page during the test, so Total Blocking Time is shown as a stand-in for responsiveness.
The two often disagree. A lab test on a throttled mobile profile can look worse than your real visitors' experience, or better if your real visitors are on slow devices. When they disagree, trust field data for "how are we doing" and lab data for "did my last change help".
What to do with a failing metric
Slow LCP
- Find the LCP element in the lab report. It is often a hero image, a large heading or a video poster.
- Serve that image in a modern format at the right size, and do not lazy-load it.
- Add a preload hint or fetch priority for the LCP image.
- Reduce server response time; a slow first byte delays everything.
- Remove render-blocking CSS and JavaScript from the top of the page.
Poor INP
- Break up long JavaScript tasks so the main thread can respond between them.
- Delay or remove heavy third-party scripts such as chat widgets and tag managers.
- Avoid expensive work in click and input handlers; show feedback first, then do the work.
- Check for large DOM sizes that make every update slow.
High CLS
- Set width and height on images and video so the browser reserves space.
- Reserve space for ads, embeds and banners before they load.
- Avoid inserting content above existing content, such as cookie bars that push the page down.
- Use font-display settings and matched fallback fonts to reduce font swap shifts.
A single check is a snapshot
Speed changes with every deploy, plugin update, new tag and content edit. A page that passes today can fail next month without anyone touching the code you think of as "the site". Vitals Clock runs this same check every day, keeps the history, and emails you when a metric crosses a threshold or gets meaningfully worse than its seven-day median.
Questions
Why is there no field data for my page?
The Chrome UX Report only includes pages and origins with enough eligible traffic. New or low-traffic pages often have none.
Why does my score differ from last time?
Lab tests vary between runs because of network and server timing. Run the check a few times, or monitor the page to see the median.
Does passing Core Web Vitals guarantee better rankings?
No. Page experience is one of many signals. Passing removes a possible weakness; it does not override content relevance.