PageSpeed Insights gets a long-overdue redesign

The PageSpeed Insights (PSI) codebase has been running for a decade, and it shows. The team behind the performance tool has announced a UI redesign addressing long-standing navigation issues and a fundamental problem: the difficulty in distinguishing between lab data and real-user field data. The updated PSI, slated for release later this year, aims to make the report easier to interpret so developers can act on insights faster.

Field and lab data are now clearly separated

The primary change is structural. Field data, sourced from the Chrome UX Report (CrUX), now sits at the top of the report. The previous single-word "passed" or "failed" Core Web Vitals assessment is now its own subsection with a distinct icon. The traditional Lighthouse performance score has moved down into the Lab data section. The goal is to eliminate ambiguity about where a score comes from and what it represents.

There is no change to how Core Web Vitals are assessed. The metrics FID, LCP, and CLS are aggregated at the page or origin level. An aggregation passes if it has sufficient data in all three metrics and the 75th percentiles are all Good. If FID data is insufficient, the assessment passes only if the 75th percentiles of both LCP and CLS are Good. If either LCP or CLS lacks sufficient data, the aggregation can't be assessed.

Navigation between mobile and desktop reports has also been simplified. Instead of burying platform links in a top menu, PSI now includes mobile and desktop links centrally on the report page. The Origin Summary, which previously required clicking a checkbox, is now its own tab under the Field Data section.

More context for every metric

Each field and lab data card now includes an information section at the bottom detailing the conditions under which the data was collected. This includes the collection period, visit durations, devices, network connections, sample size, and Chrome versions. This added context should help users who are uncertain how lab and field data can differ.

A new "Expand view" feature adds a drill-down function to the field data section, allowing users to view granular details for the Core Web Vitals metrics.

web.dev/measure is being aligned with PSI

To reduce tool inconsistency, web.dev/measure is being updated to be powered directly by the PageSpeed Insights API. Previously, /measure originated tests from a U.S.-based backend, which could produce different Lighthouse results than PSI. Now both tools call the same API. The signed-in experience for /measure is going away, but the most-used feature—seeing multiple categories—remains.

What the report looks like today

The current PSI report includes performance data for both mobile and desktop in separate tabs. The report structure includes:

  • Performance Score: A Lighthouse-derived score at the top of the report. 90 or above is Good; 50-90 is Needs Improvement; below 50 is Poor.
  • Field Data: CrUX data showing real-world FCP, FID, LCP, and CLS values, with green, amber, and red distribution bars indicating Good, Needs Improvement, and Poor. Scores cover the last 28 days and aren't available for pages without sufficient traffic.
  • Origin Summary: Aggregated metrics for all pages on the same origin.
  • Lab Data: Lighthouse results for diagnosing pre-release performance issues.
  • Audits: A list of all Lighthouse audits, including passed checks, opportunities, and diagnostics.

The core problem with this current design is that lab and field data points are not visually isolated. New PSI users may not grasp the context of mixed data sources, which has contributed to the proliferation of third-party guides explaining how to decipher the report. The redesign is intended to make that interpretation step unnecessary, moving developers from report generation directly to action.