Core Web Vitals Checker

Bring the right report

For field data, paste or upload a JSON response from the Chrome UX Report API. It should contain a record with its key, metrics and collection period. A screenshot or an average copied into a spreadsheet does not preserve the same evidence. Use a separate report for each device and URL or origin you want to review.

For a lab review, run Lighthouse in Chrome DevTools, then open the report menu and choose Save as JSON. Upload that file under Lighthouse lab report. A PageSpeed Insights API response containing lighthouseResult also works. The upload keeps the measurements and supported findings while omitting unrelated payload, such as screenshots. See Chrome’s Lighthouse instructions.

You can review either report type on its own. Lighthouse-only input produces a lab report with no field assessment. Current and previous inputs expect CrUX record responses, not the History API’s time-series format or legacy PSI loadingExperience objects. Imported reports are supplied evidence; this checker cannot authenticate where a pasted JSON file came from.

Read the three metrics

LCP concerns when the largest content element appears. INP concerns responsiveness to interactions. CLS describes unexpected visual movement. The field review uses each metric’s 75th percentile, not its average or a single visit.

The good thresholds are LCP at or below 2,500 milliseconds, INP at or below 200 milliseconds, and CLS at or below 0.1. All three supplied values must meet their threshold for the report to show all-good. If a metric is absent, the overall assessment remains incomplete even when the other two are good. These are Google’s published metric thresholds, not a score invented by EduGuestPost.

A result close to a boundary deserves context. Compare the reporting dates, audience and distribution before treating a small change as a successful fix. The histogram, when present and consistent, shows the supplied distribution bins. It is not used to interpolate a missing p75.

Page or whole site?

A page record describes the URL in the report. An origin record combines eligible experience across that origin. An origin-level good result does not certify every product page, article or checkout flow. Check the scope label before making a page-specific claim.

The optional live connection queries the exact scope and device selected. It never silently replaces a missing page record with origin data. CrUX can have no eligible record for a page; that absence is not evidence of speed, poor quality or deindexing. Its API documentation explains the record dimensions and collection period.

Compare like with like

Add a previous CrUX response to see numeric changes. The checker requires matching URLs or origins, scope, device and period length, with the previous period ending earlier. A desktop report is not accepted as a baseline for a phone report.

The report flags overlapping collection periods because they share observations. A change between two rolling windows is descriptive; it does not isolate the effect of a deployment. Keep your release date and any audience changes in the investigation notes outside this report. Recheck comparable evidence after enough new observations have accumulated.

Use lab findings carefully

Lighthouse records a controlled run; field data reflects eligible real visits. Device conditions, page state and the population being measured differ. A high lab score can therefore sit beside a field metric that needs attention without either report being broken. web.dev explains these differences.

Total Blocking Time is shown as TBT in the lab table. It is not substituted for INP. A navigation audit does not reproduce every interaction someone performs during a visit. When INP is the concern, inspect the actual slow interactions and the work they trigger. Google’s INP optimization guide is a useful next reference.

Supported Lighthouse findings retain their audit titles and estimated savings. Those estimates can overlap, so adding them together would overstate the likely gain. Treat a finding as a place to investigate, not an instruction to remove a resource without checking its purpose. The report preserves the Lighthouse version, device, throttling method and run warnings to make that review easier.

Keep a useful handoff

Download the full JSON report for context, or the metrics CSV for your tracking sheet. Give the developer the affected URL, device, collection dates, metric and relevant lab finding. After a change, repeat the same measurement process rather than comparing an unrelated fresh lab score with an old origin report.

This plugin does not save submitted JSON or reports. Imported local or staging Lighthouse URLs are treated only as text evidence; the checker does not visit them. Live CrUX requests send the selected public target to Google through a configured server-side connection. Shared abuse protection uses salted IP hashes and usage dates; hosting and verification-provider policies apply separately. Do not upload reports containing confidential information.

Good Core Web Vitals support a better experience, but this report does not determine Google indexing or promise rankings. Use the Rendered HTML Checker when the question is whether content or metadata changes after loading, and the Indexability Checker for the separate crawl-directive review.

Questions