Why doesn't this tool just run a live speed test on my URL?

Because a real Core Web Vitals measurement - lab data especially - requires actually running a page through a browser engine (Lighthouse runs inside headless Chrome) or querying Google's Chrome UX Report backend for field data, and neither is something a static, client-side-only site can do; there's no server here to make that call. Instead this tool parses a report you've already generated with PageSpeed Insights, which does have that infrastructure behind it.

Where do I get the JSON to paste in?

Run your URL through PageSpeed Insights at pagespeed.web.dev, then either use your browser's DevTools Network tab to find the runPagespeed (or pagespeedonline) request and copy its response body, or call the PageSpeed Insights API directly with your own API key and paste what it returns. Either source produces the same JSON shape this tool parses.

What's the difference between the 'lab' and 'field' results this tool shows?

Lab data (from lighthouseResult.audits) comes from one simulated Lighthouse run against a controlled network/device profile at the moment you requested the report - useful for debugging, reproducible, but not what real visitors experienced. Field data (from loadingExperience.metrics) is the Chrome UX Report: real anonymized measurements from actual Chrome users visiting that URL, aggregated over the trailing 28 days. They can disagree, sometimes significantly, and Google's ranking systems use field data, not lab data.

Why does this tool check for both FID and INP field metrics?

First Input Delay (FID) was one of the original three Core Web Vitals but was formally replaced by Interaction to Next Paint (INP) as the responsiveness metric in March 2024, since INP measures the full interaction latency rather than just the initial delay. Older or cached PSI responses may still report FID_MS instead of, or alongside, INTERACTION_TO_NEXT_PAINT, so this tool checks for either key and labels FID as deprecated when found.

My pasted JSON has metrics but the tool says none were found - why?

PSI's response shape has changed across API versions, and this tool specifically looks for lighthouseResult.audits. .numericValue and loadingExperience.metrics. .percentile. If you pasted only a subset of the response, an already-summarized report, or a different tool's export format entirely, those paths won't exist. Paste the full, unmodified JSON response for the most reliable result.

Core Web Vitals Report Analyzer - Parse PageSpeed Insights JSON

Overview

Introduction

PageSpeed Insights' report page is genuinely useful, but its raw JSON response - the thing you get from the API or from copying the underlying network request - bundles two very different kinds of measurement into one payload, keyed by long, easy-to-mistype field names, with values in raw milliseconds rather than the graded good/needs-improvement/poor labels the report page shows visually.

This tool parses that JSON directly: it pulls out every Core Web Vitals metric it recognizes, converts raw values into human-readable units, and grades each one against Google's own published thresholds, so you can inspect a PSI response the same way the official report does without re-running anything.

What Is Core Web Vitals Report Analyzer?

A defensive JSON parser and threshold grader for PageSpeed Insights API responses. It is explicitly not a live testing tool - it cannot run Lighthouse or query the Chrome UX Report itself, since both require server-side infrastructure a static client-side site doesn't have.

It reads two independent sections of a PSI response when present: lighthouseResult.audits (lab data, from one simulated run) and loadingExperience.metrics (field data, from real Chrome users over the last 28 days), and reports both separately, clearly labeled.

How Core Web Vitals Report Analyzer Works

The pasted text is parsed as JSON inside a try/catch, since a malformed or partial paste is the most common failure mode; on failure the tool explains what's expected rather than throwing a raw parse error. On success, it walks lighthouseResult.audits looking for largest-contentful-paint, cumulative-layout-shift, total-blocking-time, first-contentful-paint, speed-index, and interactive, reading each one's numericValue.

It separately walks loadingExperience.metrics (falling back to originLoadingExperience.metrics when the URL-level data is absent) looking for the CrUX field-data keys, reading each one's percentile - noting that CrUX reports Cumulative Layout Shift as that percentile multiplied by 100, which this tool automatically divides back down before grading. Every found metric is graded good/needs-improvement/poor against Google's published thresholds and displayed with its raw value.

When To Use Core Web Vitals Report Analyzer

After running a PageSpeed Insights report, to inspect the underlying numbers in one place alongside their thresholds, rather than reading gauge colors off the PSI report page.

When comparing lab data against field data for the same URL to understand whether a synthetic Lighthouse run reflects what real visitors are actually experiencing, since the two can diverge meaningfully.

Often used alongside Mobile-Friendliness Checker and Meta Tag Checker.

Features

Advantages

Handles multiple PSI response shapes defensively (missing sections, absent field data for low-traffic URLs, the FID-to-INP metric rename) instead of assuming one exact structure.
Automatically corrects the CrUX CLS percentile-times-100 quirk that trips up anyone reading that field manually for the first time.
Clearly separates lab and field results instead of blending them, since conflating a single simulated run with real-user aggregate data leads to wrong conclusions.

Limitations

Cannot generate a report itself - it only parses JSON you already obtained from PageSpeed Insights, so it's only as fresh as whenever that report was run.
Field (CrUX) data is only present for URLs with enough real-world Chrome traffic to meet Google's reporting threshold; low-traffic pages will show lab data only, with no field-data section to parse.

Examples

A PSI response with both lab and field LCP data

Input

{"lighthouseResult":{"audits":{"largest-contentful-paint":{"numericValue":3120,"score":0.63}}},"loadingExperience":{"metrics":{"LARGEST_CONTENTFUL_PAINT_MS":{"percentile":2100,"category":"FAST"}}}}

Output

Lab data (Lighthouse, this run only):
LCP: 3.12 s - needs-improvement (good ≤ 2.5 s, poor > 4 s)

Field data (real users, 28-day CrUX average):
LCP: 2.10 s - good (good ≤ 2.5 s, poor > 4 s)

The single Lighthouse run measured a slower LCP than what real users typically experience according to CrUX - a common pattern when the lab run's simulated network/CPU throttling is stricter than typical real-world conditions.

Best Practices & Notes

Best Practices

Prioritize field data over lab data when the two disagree, since Google's ranking systems use real-user CrUX data, not a single Lighthouse run, to evaluate Core Web Vitals.
Re-run PageSpeed Insights and re-paste fresh JSON periodically rather than acting on a single snapshot, since both lab conditions and real-user field data drift over time as a site and its traffic change.

Developer Notes

CrUX's CUMULATIVE_LAYOUT_SHIFT_SCORE.percentile field is documented as the CLS score multiplied by 100 (a value of 10 means a real CLS of 0.10); this tool applies a 0.01 scale factor specifically to that field before grading so displayed values match the 0-and-up decimal scale CLS is normally discussed in.

Core Web Vitals Report Analyzer Use Cases

Inspecting the exact raw metric values behind a PageSpeed Insights report's colored gauges
Comparing lab (Lighthouse) and field (CrUX) LCP/CLS/INP numbers for the same page to spot where synthetic testing diverges from real users
Archiving and reviewing a PSI JSON snapshot from a specific point in time, e.g. before and after a performance fix

Common Mistakes

Reading a CrUX CLS percentile value directly as the CLS score without dividing by 100, making a genuinely good 0.05 CLS look like a wildly poor 5.0.
Treating a single lab (Lighthouse) run as representative of all users' experience, when field data from real Chrome traffic - when available - is what actually reflects real-world performance and what Google's ranking systems consider.

Tips

Paste the full, unmodified PSI JSON response rather than a trimmed excerpt - the parser looks for metrics at specific nested paths, and trimming the surrounding structure will make it report nothing found.

Core Web Vitals Report Analyzer