Deduplicating Joins Across Citation, Referral, and CRM Data
Website owners comparing citation reports with referrals and customer relationship management (CRM) outcomes need to keep the three record types separate. A…
Categories
How to Read Core Web Vitals Alongside Lab Performance Tests
When you check a website’s Core Web Vitals, you may see results from real visits alongside results from a controlled test. Each source answers a different question. Field data shows how real users experienced the site. Lab tests help you reproduce and investigate a specific performance problem.
Use field data to see whether real visitors experience a problem, then use lab evidence to investigate its cause. A lab score alone cannot show whether real users have good Core Web Vitals. A field result alone often cannot show what caused a poor experience.
Field data and lab tests measure different things
Field data comes from real page visits. Google’s Chrome User Experience Report (CrUX) combines data from Chrome visits that meet its eligibility criteria. Visitors use different devices and networks, visit from different locations, and behave differently, so the result reflects a range of conditions. CrUX does not include every visitor. A page might not have enough eligible data to appear in a report. (CrUX methodology)
Lab data comes from a test run in a particular browser under set conditions. Lighthouse, for example, lets you inspect a page and investigate possible problems in a repeatable way. You can use the same test setup to compare a page before and after a code change. Each run represents one test scenario, while real visits span a range of conditions. (Lighthouse in Chrome DevTools)
PageSpeed Insights (PSI) shows field data alongside a Lighthouse lab report when field data is available. Read them as separate evidence. The field result summarizes real visits over time; the lab result describes a controlled test. A lab value does not predict the field percentile. (About PageSpeed Insights)
Google evaluates the three Core Web Vitals at the 75th percentile (p75). At p75, 75% of measured experiences fall at or below this value, so a “good” result does not mean every visit met the threshold. (Core Web Vitals thresholds)
| Metric | What it measures | Good at p75 |
|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the largest visible content element appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds visually to user interactions | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much unexpected movement occurs in the visible layout | 0.1 or less |
Values above the good threshold but within these ranges need improvement: LCP above 2.5 seconds and up to 4 seconds, INP above 200 and up to 500 milliseconds, and CLS above 0.1 and up to 0.25. Higher values are poor. CLS is a score, not a time measurement.
Read PSI and Search Console by scope
In PSI, check whether you are looking at field data or Lighthouse results before comparing numbers. Then check whether the field data covers the specific URL or the broader website origin, meaning the site’s domain and protocol. If PSI has no field result, the report lacks eligible data for that view. That does not show that the page performs well.
Search Console’s Core Web Vitals report groups similar URLs. Its results may therefore differ from a PSI report for one URL. Check the device category and URL group before deciding that the figures disagree. (Search Console Core Web Vitals report)
CrUX field data covers a rolling 28-day period, which updates over time. A recent improvement or decline might not appear in the field result right away. Use a lab test to check a change soon after deployment, then follow the field trend as the reporting period updates. (CrUX API documentation)
Use agreement and disagreement to choose your next check
| Field result | Lab result | What to do next |
|---|---|---|
| Poor | Poor | Treat the field result as evidence of user impact. Use the lab trace to find a likely cause, then check whether the relevant page state or interaction is covered. |
| Poor | Good | Check whether the lab test represents the affected URL, device, content variant, or interaction. A good test run does not disprove a field problem. |
| Good | Poor | Repeat the test with the same URL and settings. Investigate the lab issue, especially if it could affect users on slower devices or networks, but do not label the field experience poor on that evidence alone. |
| Good | Good | The measured field percentile and test scenario meet their respective targets. This does not establish that every visit, page variant, or interaction is problem-free. |
Before drawing a conclusion, compare the metric, URL scope, and device category. When you test a code change, use the same browser and test conditions for each run. The test machine’s workload can affect Lighthouse results, so a small difference between runs does not by itself show that the code changed performance. (Lighthouse test guidance)
Diagnose the metric the test actually measures
For LCP, check which element the test identifies as the largest content element and where that element’s loading time goes. The total includes the server’s initial response, any wait before the browser requests the resource, the download time, and any wait before the browser displays it. A late image request points to a different problem from an image that downloads quickly but appears late. Check the network waterfall, which charts requests and their timing, and the LCP timing breakdown before focusing on image compression alone. (How to optimize LCP)
For INP, investigate interactions such as clicks, taps, or key presses. A standard Lighthouse page-load audit does not test a real user journey, so it cannot establish the page’s INP. Lighthouse reports Total Blocking Time (TBT), which measures how long the page’s main thread is blocked during the lab load. The main thread handles browser work such as responding to interactions. TBT can help reveal work that might delay those responses, but it does not stand in for INP. A low TBT does not prove that every interaction responds quickly, and a high TBT does not prove that users experienced poor INP. Use a trace that records interactions or real-user monitoring (RUM), which collects performance details from visits to your own site, to investigate the interactions that matter. (INP guidance, TBT guidance)
For CLS, look for content that appears without space reserved for it, such as images, embeds, or ad slots. Then test beyond the initial page load. Scroll to content that loads as you reach it, and try interactions that reveal or insert new elements. A test that checks only the initial load can miss shifts that happen later in a visit. (CLS guidance)
Keep the SEO conclusion proportional to the evidence
Google includes Core Web Vitals in its ranking systems as part of page experience, but a good report does not guarantee top rankings. Treat a poor field result as a performance problem real users experience and investigate it; the result does not prove a specific ranking loss. A passing result describes the measured experience, but it does not promise better search visibility. (Google Search Central on page experience)
For SEO, fix problems that field data shows users experience. Use lab tests to investigate and verify likely causes. Also consider content relevance and other search factors; a performance score alone does not determine a page’s ranking.
Key Takeaways
- Start with field data: It shows whether a performance problem appears in eligible real visits; check the URL scope and device category before interpreting it.
- Use lab tests to investigate: Reproduce the relevant page state, inspect the metric-specific evidence, and compare runs under consistent conditions.
- Match the evidence to the metric: TBT can help diagnose blocking during load, but it is not INP; a load-only test can also miss later layout shifts.
- Allow for field-data delays: CrUX uses a rolling 28-day period, so use lab results for an early check and field data to follow the broader trend.
- Avoid ranking guarantees: Core Web Vitals inform Google’s page-experience assessment, but passing thresholds does not guarantee higher rankings.
What I'm buildingDelegate tasks. Get software.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.com