Why field data should lead your Core Web Vitals work
Core Web Vitals are user-centric metrics, designed to reflect how real visitors experience load performance, input responsiveness, and layout stability. That makes them fundamentally a field-data concern. Lab tools like Lighthouse are useful for diagnosis, but they run under fixed, simulated conditions that represent only one narrow slice of the real-world variety in network speed and device capability.
There are other reasons lab measurements can diverge from reality. Lighthouse performs a cold load as a brand-new visitor, which is often the slowest possible scenario. Returning visitors may have cached assets, and real users browsing a site page-to-page will have a different experience than a first-time visitor. New visitors may also encounter cookie banners or other content that lab tools do not account for consistently.
The practical takeaway: use field data to measure actual performance and use lab tools to investigate and iterate on fixes. Google's own view of Core Web Vitals comes from the Chrome User Experience Report (CrUX), a public dataset of real Chrome user experiences that powers many Google and third-party reporting tools. CrUX is excellent at telling you when something is wrong, but it often lacks the granularity to explain why.
Build your own field dataset when you can
The best field data for improving your site is the data you collect yourself from your own visitors. The approach depends on your organization's size and budget. Paid real-user-monitoring (RUM) solutions almost always include Core Web Vitals tracking and typically offer rich tooling for exploring the data—often the right choice for larger teams.
If you don't have the budget for a commercial RUM product, Google's web-vitals library is a practical alternative. It measures all Web Vitals, but leaves the reporting, storage, and analysis infrastructure to you. If you already use Google Analytics, you can send Web Vitals data collected via the web-vitals library to GA4 and then query it through BigQuery exports for reporting. That path lets you build a useful field-data pipeline without standing up a separate analytics stack.
Choosing the right Google tool for Core Web Vitals work
Google offers a range of tools for working with Core Web Vitals, and each has distinct strengths and limits. Mapping them against your workflow—whether you're debugging a single interaction, monitoring a production rollout, or building a new page—helps you pick the right one rather than defaulting to whatever is most familiar.
Chrome User Experience Report (CrUX)
The Chrome User Experience Report is a public dataset of field data gathered from a segment of real Chrome users across millions of websites. It covers Core Web Vitals and related metrics for sites with sufficient traffic. CrUX is published as a monthly BigQuery dataset at the origin level, and also as a daily API at the URL or origin level for properties that have enough samples. A range of third-party and Google tools consume this data for both programmatic and visual access.
When CrUX fits
Even if you run your own real-user monitoring, CrUX offers a useful point of comparison. Because its user base and collection method differ from a typical RUM setup, the two views will not always agree, but seeing where they diverge can be informative. If you collect no field data at all, CrUX is the fastest way to get a high-level performance read on your site—provided it meets the traffic threshold for inclusion.
Going directly to the BigQuery table or API is worthwhile when you need detail that visual dashboards often hide, such as country-level breakdowns or the additional metrics CrUX ships beyond the Core Web Vitals.
Where CrUX falls short
CrUX reflects only a subset of Chrome users. A full RUM solution captures experiences across other browsers that support the vital metrics. Low-traffic pages and origins simply don't appear in the dataset, which rules CrUX out for smaller sites or new properties. Its 28-day rolling average means changes take weeks to show up, making it a poor fit for development. Finally, as a public dataset, it supports only limited querying—you can't isolate the LCP element, compare logged-in versus logged-out users, or dig into which interactions drive poor INP values without your own instrumentation.
PageSpeed Insights (PSI)
PageSpeed Insights combines CrUX field data with a Lighthouse lab run for any public page. It reports on both mobile and desktop user experiences.
When PSI fits
PSI is a solid first stop for a page-level or origin-level field assessment, including for competitor pages. The bundled Lighthouse output hands you concrete optimization suggestions when the lab findings line up with real-world metrics. Because the Lighthouse run happens on Google's servers, results are more consistent across tests than local runs from DevTools.
Where PSI falls short
PSI cannot reach private development servers, making it useless for pre-production work. When a page or origin does not qualify for CrUX, PSI offers lab data only, with no real-user context. If you have origin-level field data but not page-level data, correlating the two can mislead—the field summary may describe the whole site while the Lighthouse audits target a specific page. Post-load CLS and interaction metrics (FID, INP) are especially hard to diagnose from lab checks, so Lighthouse advice may miss the real problem when page-level CrUX data contradicts the lab results.
Search Console
Search Console is an owner-only tool that reports on a site's search performance and includes a Core Web Vitals report sourced from CrUX field data. Its notable feature is grouping similar pages—for instance, pages sharing a template—into a single assessment unit.
When Search Console fits
The grouped view is useful for non-developers and developers alike. It shows how performance work ripples across an entire class of pages, a perspective that the other Google tools do not directly provide. If your search traffic data lives in Search Console already, the Core Web Vitals report slots into the same workflow without extra setup.
Where Search Console falls short
Teams already committed to third-party tools with their own page-grouping logic may find the overlap redundant. The usefulness of grouped audits depends on how representative the example pages are. A group's long tail of seldom-visited pages can skew the overall verdict—these pages are slower because they are less likely to be cached, and their volume can flip the group's pass rate while the example pages all look healthy.
Lighthouse
Lighthouse is a lab-based tool that generates a list of specific performance opportunities for a given page load. Lighthouse user flows let you script multi-step interaction sequences for testing beyond simple loads. Lighthouse CI runs these audits during builds and deployments, attaching the report to pull requests and tracking metric changes over time.
When Lighthouse fits
Lighthouse is best used during development, in local and staging environments, to uncover optimization leads before code ships. Lighthouse CI brings the same checks into the build pipeline, acting as a regression gate for performance-sensitive changes in staging and production deploys.
Where Lighthouse falls short
Lighthouse is not a substitute for field data. Its audits describe a single predefined page load and surface generic best practices that may not match what real users experience. The tool's diagnostics are a supplement, not a verdict. Ideally, Lighthouse stays in development and CI loops rather than serving as the primary production monitoring tool, where its single-run, synthetic view can miss user-visible issues entirely.
Performance panel in Chrome DevTools
The Performance panel is an in-browser lab tool with two distinct views. The first is a live metrics screen that shows current Core Web Vitals on the page as you interact with it; you can also pull in CrUX field data for context on the same page. The second is a full trace capture mode that records all browser activity—network, rendering, painting, scripting—during a load or a chosen time window. The trace view includes insights in the style of Lighthouse audits but with far more depth, down to call stacks and individual main-thread tasks.
When the Performance panel fits
The live metrics view is a quick way to see a page's current performance profile as you interact with it—particularly useful for spotting post-load CLS or INP issues during real use.
The trace view is the strongest option for tracking down slow interactions that affect INP. Once you can reproduce a sluggish response, the panel shows what actually happened in the browser: main-thread blocking, long JavaScript call stacks, or rendering bottlenecks. It is the place to go when you already have a concrete, repeatable problem and need root causes.
Where the Performance panel falls short
As a lab tool, the panel does not replace field data, even with the CrUX import for context. Its trace view is dense with specialized information; novice developers and non-technical stakeholders may struggle to interpret it. The live metrics view addresses that by serving as a simpler entry point for those who only need a quick current-state reading.
Building a Core Web Vitals maintenance loop
Keeping Core Web Vitals healthy isn't a one-off task; it's a continuous process. A practical workflow has three repeating stages: evaluate the current state of your site, debug and fix what's broken, and monitor to prevent regressions.
Start with field data to evaluate site health
The first step is understanding what your real users are experiencing. Field data is the most reliable signal here.
- PageSpeed Insights (PSI): This tool pulls CrUX data from the last 28 days at the 75th percentile, giving you an origin-level overview and a per-URL view. If 75% of experiences meet the threshold for a metric, it's considered "good".
- Search Console: The Core Web Vitals report is useful for identifying groups of underperforming pages. It's particularly effective when your site has pages that share common characteristics, like product or category pages on an e-commerce site.
- Your own RUM data: If you have it, this is often the most precise way to isolate issues to specific pages or traffic segments. If not, CrUX data is usually sufficient to point you in the right direction, provided your site is represented in the dataset.
When starting without a specific target, begin with your home page in PSI, as it is typically the most visited. Compare mobile and desktop views, and note that mobile will generally be slower due to hardware and network constraints. A significant gap between URL-level and origin-level data often indicates that your home page is a landing page where users take the full impact of an unprimed cache.
PSI shows all three Core Web Vitals metrics in this view—LCP, CLS, and INP—plus TTFB and FCP. Use the relationships between these to diagnose issues. For example, a slow LCP with a high TTFB points to backend, server, or network problems rather than issues with the LCP resource itself. Checking CrUX's newer diagnostic breakdowns can help here. For CLS, compare the CrUX score against Lighthouse's to determine whether shifts happen during load or after. For INP, look at Lighthouse's TBT audits, but remember that lab tests without interactions can't fully capture INP issues.
Drill down to debug with DevTools
Once you've identified problem pages, you can move to debugging. Use lab tools to validate the issues are the same ones you're trying to fix, then get granular with the following:
- Lighthouse: Run it from PageSpeed Insights or directly in Chrome DevTools to validate fixes. Filter the audits to specific Core Web Vitals metrics to see only relevant guidance.
- Performance panel – Live Metrics: This view shows real-time Core Web Vitals during page load and while browsing, meaning it can catch INP and post-load layout shifts that Lighthouse misses.
- Performance panel – Tracing: Record a complete profile of page behavior to drill down. Use the Insights side panel for automated diagnostics, click on LCP in the Timings track, examine the Layout Shifts track to see which elements moved, and look for red triangles in the flame chart that indicate long tasks contributing to INP issues.
These tracing features let you verify that your code changes have the desired effect before shipping them to production.
Monitor constantly with CI and field trend data
The final stage is about prevention. Even with regular testing, you need a safety net to prevent regressions from reaching users.
Lighthouse-CI is a key tool here, allowing you to run audits automatically on code commits. You can fold it into CI pipelines to check for performance regressions or use it as a linting tool to catch bad practices based on specific performance audit results.
For the field side, a robust RUM solution is essential. The web-vitals JavaScript library automates collecting field data, which you can feed into custom dashboards and alerting to catch issues that pass through CI. For sites that don't have RUM set up, the various CrUX tools provide a way to perform basic field data trend analysis.
