Core Web Vitals Measurement Tools

The Tools at a Glance

Chrome’s CrUX documentation lists the access points: CrUX Vis, CrUX on BigQuery, the CrUX API and the CrUX History API, as well as PageSpeed Insights. CrUX also powers Search Console’s report: web.dev’s Web Vitals overview says it “powers tools like Chrome DevTools, PageSpeed Insights, and Search Console’s Core Web Vitals report.”

Field Data: Is the Site Passing?

Search Console’s Core Web Vitals report is the starting point for a site, because it groups similar URLs and shows which groups are Poor, Need improvement or Good on mobile and desktop. Use it to choose templates to fix, and its validation flow to confirm a fix.

PageSpeed Insights gives field data for one URL, falling back to the whole origin when the URL lacks data. How to read it is in PageSpeed Insights and Lighthouse.

CrUX Vis and the History API show trends. The History API documentation says it “contains the previous 40 weeks (approximately 10 months) worth of data, one collection period per week”, each covering the previous 28 days, so consecutive points overlap and move like a moving average. A fix shows up gradually, over several weekly points.

The CrUX Dashboard is gone. Chrome’s deprecation notice announced the Looker Studio dashboard’s deprecation after the end of November 2025 and points to CrUX Vis as the replacement. Rebuild any reporting that depended on it on CrUX Vis, the History API or BigQuery.

Lab Data: Why Is It Failing?

Lighthouse runs one simulated load and lists insights with estimated savings; it runs in PageSpeed Insights, DevTools, the command line and as a Node module. Use it to test a fix before release.

The DevTools Performance panel records your own session, including interactions, which Lighthouse’s page load doesn’t cover. It now includes what the old Web Vitals extension did: Chrome’s announcement says “the Web Vitals extension has officially merged with the Performance panel in DevTools” and that support for the extension has ended. Use the panel to reproduce a slow interaction (INP) or a layout shift (CLS) on a real device.

Lab tools can’t confirm a field result. A page that passes in the lab can fail for visitors on slower devices or after interactions the lab test never made.

Your Own Real-User Monitoring

CrUX covers Chrome users on pages with enough traffic. To measure the pages it misses and segment by your own dimensions, collect the metrics yourself. web.dev says “The easiest way to measure all the Core Web Vitals is to use the web-vitals JavaScript library”, describing the web-vitals library as a wrapper that measures each metric “in a way that accurately matches how they’re reported by all the Google tools listed earlier.” Send the values to your analytics as events, with the page template and device.

Expect differences: web.dev notes that metrics “measured in JavaScript using public APIs may differ from the Core Web Vitals reported by CrUX.” Your RUM covers your visitors on all browsers you measure; CrUX covers Chrome users who meet its criteria.

Third-party RUM services offer the same data with dashboards and alerts; choose one by whether it measures Core Web Vitals with the web-vitals definitions and lets you segment by template.

Combining the Tools

1. Find failing groups in Search Console’s Core Web Vitals report.
2. Pick a representative URL and open it in PageSpeed Insights for field values and lab insights.
3. Reproduce the problem in Lighthouse or the DevTools Performance panel.
4. Fix by template and test the change in the lab.
5. Watch the field trend in CrUX Vis or your RUM data over the following weeks.
6. Validate the fix in Search Console once the field data reflects it.

Fixes are covered in improving LCP, INP and CLS; crawler integrations that pull PSI data for a large set of URLs are in Screaming Frog SEO Spider.

Treat a fix as confirmed only when the field trend has moved over several weekly CrUX points and Search Console’s validation passes; a better Lighthouse score on its own doesn’t confirm it.