Free tool, data from Google PageSpeed Insights
Core Web Vitals Checker with real user data
See how real Chrome users experience a page: LCP, INP and CLS at the 75th percentile, whether the page passes the Core Web Vitals assessment, and what to fix first.
Check Core Web Vitals
Enter a page. Mobile and desktop are tested in parallel, which takes 10 to 40 seconds.
Why use the Core Web Vitals Checker
Field data
The Chrome UX Report numbers Google uses in search: real visits over the last 28 days, for the url and the whole origin.
Lab data
A Lighthouse run with the performance score, LCP, CLS, Total Blocking Time, Speed Index and server response time.
Mobile and desktop
Both are tested at once. Switch between them without waiting again.
What to fix
The opportunities with the largest estimated saving, in plain words.
When to use the Core Web Vitals Checker
Search Console warnings
Check a url group that Search Console reports as poor or in need of improvement.
After a release
Confirm that a new template did not slow real visits down.
Competitors
Compare your field data with the pages you compete with.
Client reports
Share a clear pass or fail for the three Core Web Vitals.
Prioritising
See whether LCP, INP or CLS is the problem before you start optimising.
Low traffic pages
Fall back to the origin data when a single url has too few visits.
Understanding Core Web Vitals
How to read the result
- 1Assessment. A page passes when LCP, INP and CLS are all good at the 75th percentile of visits.
- 2Field data. What real visitors experienced. This is what counts for search.
- 3Lab data. One simulated load. Use it to find causes and to test changes.
- 4Opportunities. The fixes Lighthouse estimates would save the most time.
The thresholds
LCP is good at 2.5 seconds or less and poor above 4 seconds. INP is good at 200 milliseconds or less and poor above 500. CLS is good at 0.1 or less and poor above 0.25. FCP and TTFB are shown for diagnosis but are not part of the assessment.
When there is no field data
Chrome only reports a url when enough people visited it. For quieter pages the tool shows the data of the whole origin. New and low traffic sites may have none at all; the lab data is still useful.
Where the data comes from
The tool asks Google PageSpeed Insights, which runs Lighthouse on Google's servers and reads the Chrome UX Report. Aback keeps no copy of the result. The page you test is loaded by Google, not by Aback.
Related tools and guides
Frequently asked questions
What is the difference from the page speed test?
The page speed test loads the page from Cloudflare's network and explains the causes. This checker shows Google's own data, including real user field data that only Google has.
Why is there no INP in the lab data?
INP needs real interactions. Lighthouse reports Total Blocking Time instead, which tends to move with INP.
Why do field and lab data disagree?
Field data covers 28 days of real devices and networks. The lab run is one load on one simulated device. Both are right about different things.
How often does field data update?
The Chrome UX Report is a rolling 28 day window, so a fix shows fully in the field data after about four weeks.
Do Core Web Vitals affect rankings?
They are part of Google's page experience signals. They matter most when pages are otherwise similar, and they always matter to visitors.
Why did the test fail?
Google could not load the page: it may block Google's servers, need a login, or take too long. The error says what Google reported.
How many tests can I run?
Thirty an hour from one network. Each test of mobile and desktop counts as two.