Stage 1: Access

Core Web Vitals check

Field and lab Core Web Vitals for one page from Google's PageSpeed Insights API, each metric against Google's published thresholds.

Free to use. No login, nothing stored.

What it checks

Access

LCP, INP and CLS from Chrome users at the 75th percentile, mobile or desktop
Share of page loads that were good, needs improvement and poor for each metric
Origin-level field data when the URL itself has too little Chrome traffic
Lab metrics from a single Lighthouse run by Google, labelled as such
One click to run the other form factor, and a link to the full report

Method question for this stage: Can crawlers reach and render every key page?

Run the check

Page address (required)

Google's PageSpeed Insights API runs the test; allow up to 45 seconds. Field data appears when the page has enough Chrome traffic. Nothing is stored here.

Form factor (required)

Mobiledefault: emulated phoneDesktopemulated desktop browser

Thresholds are Google's, published on web.dev and applied to the 75th percentile of page loads, measured separately for mobile and desktop: LCP good at 2.5 s or less and poor above 4 s; INP good at 200 ms or less and poor above 500 ms; CLS good at 0.1 or less and poor above 0.25. A field row is Pass, Warning or Fail according to Google's own good, needs improvement or poor category for the metric. Lab rows are Info only.

Data comes from Google's PageSpeed Insights API: field numbers from the Chrome UX Report when the URL, or failing that the origin, has enough traffic, and one Lighthouse run by Google for the lab numbers. Google has said it plans to discontinue real-world data in this API; when that happens the field rows will go until the tool is moved to the CrUX API.

Results

No check run yet

Info
Field data first, then the lab run
LCP, INP and CLS for this URL at the 75th percentile with the share of good, needs improvement and poor page loads; origin data as Info when the URL has too little traffic; then the lab metrics from Google's single run, the Lighthouse score and the run details, all as Info.

How we check

The rules this tool tests, and where they come from

A result is a check against a published rule, not a prediction. Every row shows its working.

Rules and sources

Links go to the operator's or standards body's own documentation. We do not link to third-party summaries.

Fix what it finds

This check belongs to the Access stage of the Crawl-to-Citation Method. The service below covers the fix; the Diagnostic ranks it against everything else.

Technical SEO

Crawl, render, index, migrate

Access

See the service

Most engagements start with the Search Visibility Diagnostic ($2,500).

It covers all six method stages, so what this tool finds is ranked against everything else before you commit to any work.

Book the diagnostic

All free tools

Core Web Vitals questions

What the rows mean, and where the claims come from.

Still have questions? Book a call

What is the difference between field data and lab data?

Field data is what real Chrome users experienced on the page, collected by the Chrome UX Report and reported at the 75th percentile of page loads, separately for mobile and desktop. It is the data Core Web Vitals are defined on, and the Pass, Warning and Fail rows use Google’s own good, needs improvement and poor categories for it. Lab data is one Lighthouse run that Google performs on an emulated device and network when you press the button; it is useful for spotting what to fix but it is not what anyone experienced, which is why the lab rows are Info only. web.dev puts it this way: “While lab measurement is an essential part of delivering great experiences, it is not a substitute for field measurement.” Google also states on the API page: “We plan to discontinue including real-world data from the Chrome User Experience Report in this API.” If that happens the field rows will disappear until this tool is moved to the CrUX API.

Why does the tool say there is not enough data for my page?

The Chrome UX Report only includes a page when it is publicly discoverable (indexable, served with HTTP 200, no noindex) and, in Google’s words, “sufficiently popular”, which it defines as having “a minimum number of visitors” among Chrome users who share usage statistics. Google does not publish the number. Most pages on small and medium sites fall under it, so the tool falls back to origin-level data, which aggregates every page on the host, and shows it as Info rows because it does not describe your page specifically. When the origin has no data either, only the lab run remains. Search Console’s Core Web Vitals report has the same limitation for the same reason.

Do Core Web Vitals affect Google rankings?

Google’s Search documentation says: “We highly recommend site owners achieve good Core Web Vitals for success with Search” and “This, along with other page experience aspects, aligns with what our core ranking systems seek to reward.” That is the extent of what Google states; it does not publish a weight, and this tool does not estimate one. Treat a poor metric as a user-experience problem with a documented fix, not as a prediction about a position.