PageSpeed Insights and Lighthouse report analyzer
Turn Lighthouse JSON into a version-aware action queue while keeping lab scores, field metrics and HTML evidence separate.
- SECURE
- NO UPLOADS
- NO SIGNUP
- BROWSER BASED
- FREE
- FOREVER.
Support us with a link or a share
Upload or paste a Lighthouse JSON report
The JSON and optional HTML stay in this tab. A browser worker parses the report and applies fixed rule IDs; no AI or report upload is involved.
Lab report and field data
Add the JSON downloaded from Lighthouse or a PageSpeed Insights API v5 response.
What PageSpeed Insights puts in one response
PageSpeed Insights can return two fundamentally different kinds of evidence. Its
lighthouseResult is a lab run: one controlled simulation with a recorded
Lighthouse version, device environment, URL and fetch time. When enough Chrome User
Experience Report data exists, loadingExperience and
originLoadingExperience add aggregated real-user measurements. Google documents
those fields separately in the PageSpeed Insights API v5 response.
The analyzer preserves that boundary. Lab category scores appear in one card. URL- and origin-level LCP, INP and CLS appear in another only when the JSON contains them. No formula combines the two. This matters because a single clean run can coexist with slow real-user devices, while a noisy lab run can coexist with acceptable field experience. They are clues from different populations, not two halves of one score.
Why a Lighthouse report needs its version and audit IDs
A Lighthouse JSON file is more useful than a screenshot because the structured report keeps every audit under a stable ID, records whether it passed, failed, was manual or did not apply, and can include numeric savings. Categories then reference weighted audits. This tool reads that relationship rather than trying to reconstruct a score from colorful gauges. Google’s own guide to Lighthouse results also distinguishes audit results from category groupings and weights.
Audit definitions change as Lighthouse evolves. The rule map here is deliberately bounded to major versions 10 through 13. An older or future report is not silently treated as current. Its category summary remains visible, but every version-bound rule is marked skipped. That is less exciting than guessing and much safer than recommending work against an audit that was renamed, removed or rescored.
Performance scores are queues, not universal grades
Lighthouse labels performance scores from 0–49 as poor, 50–89 as needing improvement and 90–100 as good, but Google also warns that scores vary because network routing, client hardware, browser extensions and background work vary. The uploaded score is therefore shown exactly as Lighthouse supplied it. The analyzer does not promise that turning a 62 into a 90 will produce a particular traffic or revenue change.
The action queue instead groups related failures: LCP discovery and rendering, main-thread blocking, layout stability, JavaScript and third parties, CSS, images, server delivery, accessibility and SEO fundamentals. Evidence retains each audit ID and its display value or reported savings. Start with the highest defensible queue item, make one coherent change and repeat an equivalent profile several times. A one-run score difference is not automatically proof that the change caused it.
Core Web Vitals use field thresholds at the 75th percentile
The published “good” field thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, evaluated at the 75th percentile of page loads. The uploaded PageSpeed response already carries its field categories and percentiles, so the tool displays those values rather than manufacturing a new grade. See Google’s explanation of how Core Web Vitals thresholds are defined for the population and percentile logic.
Lighthouse cannot observe representative user interaction and therefore cannot measure real-user INP. Total Blocking Time is useful in the lab because long main-thread tasks often reveal code that will also make interaction harder, but it remains a diagnostic proxy. This report never converts TBT into predicted INP. If the JSON has no field INP, the correct output is “not available,” not a derived number.
Optional HTML evidence has a narrow job
Pasting View Source HTML can confirm a few source-visible facts. The analyzer counts image tags missing either dimension, checks for a viewport meta tag and counts external script hosts written directly into the markup. Those checks can make an audit easier to route to the right template or vendor owner. They cannot see a tag manager’s runtime injections, response headers, a service worker, external CSS rules or the browser’s actual request priority.
That limitation is written into the generated finding. A source-visible signal should be connected to the matching Lighthouse evidence before it becomes work. For example, an image without dimensions supports a layout-shift investigation only when the rendered element can actually move content. The source alone cannot establish that causal chain.
A deterministic report with an explicit rule ledger
Each rule says whether it ran, which supported audit IDs were present and how many findings it produced. Missing SEO or accessibility categories are skipped rather than treated as perfect scores. Manual accessibility audits are not counted as automated passes. A report with no findings therefore means only that none of the supported conditions crossed its threshold; it is not an accessibility, SEO or performance certificate.
Priority uses impact × confidence × reach ÷ effort, with every factor shown on
each card. Lighthouse score and reported savings drive the evidence side. Your stack and
implementation access can change the likely owner or effort, while a required third-party
script changes the first action from removal to loading strategy. Download CSV for a backlog
or Markdown for a review note. If the problem is search visibility rather than page delivery,
move to the Search Console report analyzer or
begin with the interactive Google ranking diagnosis.
Your Lighthouse JSON remains on this device
The browser reads the file into this tab and sends its text to a dedicated browser worker. Parsing and scoring happen locally; no report body is sent to CreatorValet, Google or an AI provider. The worker keeps large JSON work away from the page controls, and closing the tab discards both inputs and result. If you only need to inspect or repair an unfamiliar JSON structure first, use the JSON formatter and return with the original structured Lighthouse object intact.
Questions
Which Lighthouse JSON file can I upload?
Use the JSON output from Chrome DevTools or the Lighthouse command line, or paste a PageSpeed Insights API v5 response that contains lighthouseResult. The analyzer requires an object with Lighthouse audits and categories. A screenshot, HTML report or unrelated performance summary is not enough because it does not preserve stable audit IDs, scores and structured savings. The current deterministic audit map supports Lighthouse major versions 10 through 13. Reports outside that range still show their own category scores, URL and timestamp, but the action rules are skipped and the ledger explains why.
Why are PageSpeed field data and Lighthouse lab data separate?
They answer different questions. Lighthouse records one controlled lab run with a simulated device and network profile. PageSpeed can also include Chrome User Experience Report field metrics aggregated from real users at the 75th percentile. This tool never averages or blends them. A fast lab run cannot erase a poor real-user LCP, and sparse field coverage cannot invalidate a reproducible lab diagnosis. Each section keeps its own source and measurement boundary visible.
Can Lighthouse measure Interaction to Next Paint?
Not as a real-user interaction metric. Lighthouse runs without a representative person completing the interactions that produce INP, so it reports lab diagnostics such as Total Blocking Time instead. TBT can help find long main-thread work, but it is not converted into an INP estimate here. INP appears only when the uploaded PageSpeed response contains field data for it.
How are Lighthouse fixes prioritized?
Every finding uses impact multiplied by confidence multiplied by reach, divided by effort. Each factor is an integer from 1 to 5, and the result is normalized against the maximum raw score of 125. Audit score and reported byte or millisecond savings influence the queue; your answers about stack, access and required third parties adjust effort, ownership or the action text. They do not change Lighthouse evidence or recalculate the category score.
What does the optional HTML source add?
It adds only conservative checks visible in the supplied markup: image tags without both width and height, a missing viewport meta tag and the number of source-visible external script hosts. Static HTML cannot prove HTTP headers, runtime DOM changes, browser scheduling, network priority, external stylesheet contents or the final rendered element. The HTML rule therefore asks you to connect a source signal to a matching Lighthouse audit before changing code.
Is my performance report uploaded or processed by AI?
No. The selected file is read inside this tab and passed to a worker in your browser. Fixed TypeScript rules inspect known Lighthouse audit IDs and produce the on-page report plus CSV and Markdown files. There is no account connection, report endpoint or AI model call. Closing the tab discards the input and result.