iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Measure Core Web Vitals in both the field and the lab: field data shows how real visitors experience your site, while lab tests provide controlled runs for diagnosing problems and checking changes. Use field results to assess real-world performance; a strong lab score cannot substitute for them.
What Core Web Vitals measure
Google’s current Core Web Vitals cover loading, interactivity, and visual stability. The recommended thresholds apply to the 75th percentile of page loads, assessed separately for mobile and desktop—not to an average across devices or a single test run. See Google’s Web Vitals guidance.
| Metric | What it reflects | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading performance: when the largest visible content element is rendered. | At or below 2.5 seconds |
| Interaction to Next Paint (INP) | Interactivity: how quickly the page responds visually to user interactions. | At or below 200 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability: unexpected movement of page content. | At or below 0.1 |
Field data and lab data answer different questions
Field measurement: what visitors actually experience
Field data comes from real page visits on users’ devices and connections. Chrome UX Report (CrUX) aggregates anonymized measurements, and Google’s field tools use it when data is available. Your own real-user monitoring (RUM) can add detailed telemetry for your pages and pageviews. Field results represent a distribution of user conditions rather than one controlled setup.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Lab measurement: what happens in a controlled test
Lab data comes from synthetic tests that load a page under a defined setup. Lighthouse, Chrome DevTools, and WebPageTest can help reproduce problems and evaluate changes before release. Record the device and network conditions, along with the page and test setup, so repeated runs are comparable. A lab run is repeatable, but it does not represent the full range of actual visitors.
#1 Best Overall
Choose a tool for the question you need to answer
| Question | Tool | What it provides |
|---|---|---|
| How does the page perform for real users? | PageSpeed Insights (PSI) and CrUX | PSI combines Lighthouse diagnostics with available field data for a page or origin. CrUX field data covers a rolling 28-day period; some URLs lack sufficient data for a page-level result. |
| Which pages are affected, and how has performance changed over time? | Search Console Core Web Vitals report | Page-level field performance and historical reporting. |
| How does a local page relate to real-world context? | Chrome DevTools Performance panel | Page-level performance inspection, with CrUX context available as a starting point for debugging. |
| Can I reproduce a problem or check a change? | Lighthouse, Chrome DevTools, or WebPageTest | Controlled lab runs for development and diagnosis; consistency depends on keeping the test setup comparable. |
| Do I need detailed telemetry for my own pages? | The web-vitals library plus an analytics endpoint | Site-owned RUM can capture page-level observations. Aggregate and segment the results so they can guide specific fixes. |
A practical field-and-lab measurement workflow
- Check field data first. Enter the page URL in PSI and inspect available field results. If you need to find patterns across affected pages or over time, review Search Console’s Core Web Vitals report.
- Identify the metric and page to investigate. Note whether the issue is LCP, INP, or CLS, and whether the relevant result is for mobile or desktop. Field data can show the scale and distribution of an issue, but may not reveal its exact cause.
- Reproduce the page in a lab. Run a Lighthouse test, inspect the page in DevTools, or use WebPageTest. Record the device and network conditions and keep them consistent when comparing runs.
- Diagnose what the lab can measure. Inspect traces and page behavior for likely causes. For interaction issues, use Total Blocking Time (TBT) as a clue to main-thread blocking—not as an INP result.
- Make the change and rerun the controlled test. Compare runs using the same page and setup to see whether the change affected the behavior you targeted.
- Check field observations after the change. Use subsequent field data—or your RUM telemetry—to see whether real-user experience improves. Field distributions can differ from lab runs, and CrUX reflects a rolling 28-day period rather than an immediate before-and-after test.
Why field and lab results can disagree
LCP can include delays before visible content appears
Field LCP may include navigation-related time such as redirects, connection setup, and server response delays. It can also vary with users’ devices, networks, locations, and personalized content. A controlled lab environment may not reproduce those conditions. Use the field result to identify the gap, then inspect traces or field RUM detail to investigate it. See Google’s LCP guidance.
A Lighthouse run does not measure INP
INP depends on actual user interactions, and a standard Lighthouse page-load run does not supply those inputs. TBT can help diagnose lab main-thread blocking, but it is only a proxy: a favorable TBT result does not establish that real-user INP is good. Check field data or RUM for INP. See Google’s measurement guide.
A load-only test can miss CLS that happens later
Lab tools often capture layout shifts during initial loading, while real users may encounter shifts later as they scroll, click, or see additional content. A clean lab result therefore does not rule out a field CLS problem. Investigate the page’s full lifecycle and user-triggered behavior; Google’s CLS guidance discusses the metric, and its field debugging guide explains how to investigate real-user issues.
Aggregate field data identifies the pattern, not always the cause
CrUX can show the distribution and scale of performance problems, but aggregate data may not isolate the responsible code or event. Pair it with lab traces for repeatable inspection or with field RUM attribution for page-level detail.
Quick Recap
Best Value
- Cable tester with single button testing of RJ11, RJ12 and RJ45 terminated voice and data cables
- Tests CAT3, CAT5e and CAT6/6A cables
- Fast LED responses indicate cable status (Pass, Miswire, Open-Fault, Short-Fault, and Shield)
- Test remote stores securely in tester body
- Compact tester easily fits in your pocket
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.
