Recommended Free Tools
Use PageSpeed Insights (PSI) for a quick page check that puts Google’s real-user CrUX data beside Lighthouse lab diagnostics. Use the CrUX APIs when you need Google’s aggregated field data programmatically, and first-party real-user monitoring (RUM) when you need ongoing, more detailed measurements from your own visitors. These sources answer different questions: field data shows what people experienced; lab diagnostics help investigate what may be causing problems.
How PSI, CrUX and RUM differ
| Source | What it measures | Best use | Main limitation |
|---|---|---|---|
| PageSpeed Insights | CrUX field data plus Lighthouse lab diagnostics | A convenient check of one page, with both user-experience context and optimization clues | Field data may represent the whole origin rather than the URL; lab results are simulated |
| CrUX | Google’s aggregated real-user experience data | Querying Google’s field dataset, including through its APIs | Eligible pages need enough distinct samples; not every URL or origin has data |
| First-party RUM | Measurements collected from visits to your own site | Ongoing monitoring and investigating which visits or pages are affected | Requires collection, transmission, aggregation and reporting setup |
Do not treat the three as interchangeable scores. Before comparing results, identify whether each value is simulated or observed, whose visits it covers, whether it is URL- or origin-level, the reporting period, and how much diagnostic detail is available.
What PageSpeed Insights tells you
PSI reports separately for mobile and desktop. Its field section uses CrUX data from a trailing 28-day period; it presents the 75th percentile and the distribution of experiences. Its lab section runs Lighthouse in a simulated environment and provides diagnostics and optimization suggestions. Google’s PSI documentation explains the distinction between these parts of the report.
Read the field result at the right scope
When a URL has enough CrUX data, PSI can show URL-level field results. If not, it may fall back to origin-level data. An origin result aggregates experiences across pages on the site, so it is not evidence of how that particular URL performs. If neither URL nor origin has enough data, PSI may have no field result.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute#1 Best Overall
The 75th percentile is intended to represent the experience of the majority while still revealing difficult experiences. A passing Core Web Vitals assessment depends on the 75th percentile of each required metric being in the good range; a single favorable metric does not make the set pass.
Know the Core Web Vitals thresholds
Google’s currently documented field thresholds classify these Core Web Vitals as follows:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | 2.5 seconds or less | More than 2.5 through 4 seconds | More than 4 seconds |
| Interaction to Next Paint (INP) | 200 milliseconds or less | More than 200 through 500 milliseconds | More than 500 milliseconds |
| Cumulative Layout Shift (CLS) | 0.1 or less | More than 0.1 through 0.25 | More than 0.25 |
These are field thresholds for LCP, INP and CLS, not general Lighthouse score cutoffs. PSI may also report FCP and TTFB; those are not Core Web Vitals, and TTFB thresholds are identified as experimental in the PSI documentation.
Use lab results to investigate, not certify user experience
A Lighthouse run tests a particular simulated setup, while field data summarizes real visitors using varied devices and networks over time. Their results can differ without either being erroneous. Use the lab view to find reproducible issues or check a change before release, then use field data to see whether visitors’ experience is actually good. A green Lighthouse score alone does not prove that field Core Web Vitals pass.
What CrUX adds—and why data may be missing
Chrome User Experience Report (CrUX) is Google’s aggregated real-user experience dataset. It can provide field context without a site owner installing their own analytics instrumentation. However, CrUX inclusion depends on a page being public, crawlable and indexable, as well as having enough distinct samples for a representative anonymized view. A new or low-traffic URL may not qualify for URL-level data; PSI might then show an origin aggregate or no field data at all.
Choose the CrUX interface for the job
For programmatic access to Google’s field dataset, Google recommends the CrUX API or CrUX History API. Its PSI API guide says Google plans to discontinue including CrUX data in that API and points developers to the CrUX APIs instead. Because this direction can change, check the current API guidance before building or maintaining an integration.
Be precise when discussing CrUX BigQuery. In Google’s documented comparison with PSI field data, both use trailing 28-day periods, PSI updates daily, and BigQuery updates monthly and is limited to origin-level data in that comparison. That BigQuery scope limitation should not be generalized to every CrUX interface or API.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What first-party RUM tells you
RUM measures performance for visitors to your own site through instrumentation you select and operate. It can provide per-pageview telemetry and ongoing visibility that helps identify which visits or pages are affected by a regression. Unlike a ready-made aggregate report, a usable RUM system requires you to collect measurements, send them to a destination, aggregate them, and present them in reports or alerts.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Collect and report the metrics deliberately
Google’s field-measurement guidance recommends the web-vitals JavaScript library as one implementation option. The GoogleChrome web-vitals project documents reporting metrics to an analytics endpoint and offers an attribution build with additional diagnostic information. Merely measuring values in the browser is not monitoring unless those values are sent, aggregated and made useful to the people responsible for the site.
Assess RUM using the distribution and share of visits meeting the good threshold for each metric, not the median alone: a median can hide a slow tail. The web.dev guide describes Google’s approach as looking at the percentage of good experiences, with 75% of page visits expected to be good for each metric.
Keep the population in view
RUM and CrUX can legitimately disagree. Public JavaScript measurements do not necessarily match CrUX measurements, and a first-party RUM dataset reflects the site’s choices about collection and reporting. When comparing numbers, label the source and population rather than implying they measure an identical set of visits.
Quick Recap
Which data should you use?
| Your question | Start with | Why |
|---|---|---|
| How is one page doing, and what might I improve? | PSI | It combines CrUX field context and Lighthouse diagnostics in one report. Check whether the field result is URL-level, origin-level or unavailable. |
| How can I query Google’s field dataset in software? | CrUX API or CrUX History API | Google recommends these as it plans to discontinue CrUX data in the PSI API; verify current behavior before implementation. |
| Which of my visitors or pages are affected by a regression? | RUM | First-party collection can give ongoing, per-pageview detail, but you must build and operate the reporting pipeline. |
| Can a change be checked before visitors receive it? | Lighthouse lab tools, alongside field monitoring | A controlled lab run can reveal issues early, but does not cover the range of real-user conditions. |
| Why is a URL or origin missing CrUX data? | RUM for your own traffic; PSI or Lighthouse for lab diagnostics | CrUX requires eligible pages and sufficient samples. Your own instrumentation can measure your traffic; lab testing can still provide a simulated diagnostic view. |
A practical way to combine the sources
- Start with PSI. Check mobile and desktop, and note whether the field result is URL-level, origin-level or absent. Keep the CrUX field values distinct from Lighthouse diagnostics.
- Investigate lab findings. Use Lighthouse diagnostics to look for issues you can reproduce and address. Treat a lab improvement as a hypothesis about user impact, not proof of a field improvement.
- Use CrUX APIs for Google-data integrations. If your workflow needs Google’s aggregated field dataset in code, consult the current CrUX API or History API documentation rather than assuming PSI API field data will remain available.
- Add RUM when you need your own visit-level view. Instrument collection, transmit the metrics, aggregate them, and build reporting that exposes distributions and the share of good visits. Compare its results with CrUX only after making the different populations and collection methods explicit.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
