The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →To improve Core Web Vitals, use field data to find which real visitors and pages are affected, reproduce the problem with browser tools, make a targeted change, and check field results again. The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).
What counts as good Core Web Vitals?
Google recommends evaluating the 75th percentile of page loads separately for mobile and desktop. A page experience is considered good when it meets all three thresholds:
As an Amazon Associate I earn from qualifying purchases.
| Metric | What it represents | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the largest visible image or text block is rendered | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Interactivity: how quickly the page responds visually after user interactions | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability: unexpected movement of page content | 0.1 or less |
These are Google’s recommended “good” thresholds, published on its Web Vitals guidance, last updated October 31, 2024. Check the official Web Vitals page for the current metric definitions and thresholds; Web Vitals can evolve.
Which measurement tool should you use?
Choose based on the question you need answered. Field data establishes what visitors experience; lab tools help reproduce and inspect causes. Neither is a substitute for the other.
#1 Best Overall
| Approach | Best for | Limitations on its own |
|---|---|---|
| CrUX, PageSpeed Insights, or Search Console field data | Checking aggregated real-user outcomes and whether a problem exists | Often lacks per-pageview diagnostic detail; availability depends on the source and page population. |
Site-owned RUM with web-vitals |
Tracking your visits, page-level distributions, and attribution signals | Requires instrumentation and reporting; browser measurement has edge cases, including iframe shifts. |
| Lighthouse | Repeatable lab diagnosis and pre-release regression checks | A run without user interaction cannot measure INP and may miss interaction-dependent CLS. |
| Chrome DevTools Performance panel | Inspecting runtime behavior and tracing a page while interacting with it | A local trace does not show a population-level field distribution. |
Google’s getting-started guide explains the distinction between field and lab measurement. Aggregate field tools can show that a group of users has a problem, but they generally cannot identify the exact element or event handler responsible. A site-owned real-user monitoring (RUM) setup can add visit-level detail.
How to collect Web Vitals in JavaScript
The web-vitals library provides callbacks for LCP, INP, and CLS. Send the resulting metric data to an endpoint you control, then configure the corresponding custom metrics or events in your analytics backend as needed.
Rank #2
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify(metric);
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);This follows the basic collection pattern in Google’s Web Vitals documentation. The beacon is a non-blocking option where available; the example falls back to a keepalive request. Adapt the endpoint and payload handling to your own backend.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsKeep collection lightweight
Load analytics asynchronously and keep callback work short. A heavy monitoring bundle loaded early, or expensive processing on the main thread, can delay rendering or user input and distort the metrics it is meant to observe. Prefer collecting only the fields needed to diagnose performance, and avoid unnecessary personal data in debug dimensions.
Keep useful dimensions and distributions
Record the metric name, value, and stable metric identifier, along with carefully chosen page and device dimensions. Report distributions, not only averages: the 75th percentile is Google’s recommended point for comparing a population with the good thresholds. Segment enough to reveal differences by device class and page type without collecting dimensions that do not help explain performance.
How to debug a poor field result
- Establish the field baseline. Start with PageSpeed Insights, Search Console, or CrUX to see whether real-user outcomes are poor. If you need timely, per-pageview detail, collect site-owned RUM as well. Note the metric, device segment, and affected page types.
- Reproduce under representative conditions. Use repeatable Lighthouse or Chrome DevTools measurements with device and network conditions that resemble affected visitors. A lab result helps isolate a problem; it does not need to match a field percentile exactly.
- Inspect the relevant page state or interaction. For loading, identify the LCP candidate and its timing components. For interactivity, reproduce the slow click, tap, or keyboard action and inspect a trace. For stability, exercise post-load flows, scrolling, and hover behavior rather than checking only the initial render.
- Change the specific cause, then verify. Use lab tools to check for a controlled improvement or regression during development. After release, watch field distributions to see whether actual visitors improved, segmented by device and page type.
For an effective fix loop, use field data to answer whether users are affected and which pages or visits need attention; use lab traces to investigate what code or rendering behavior to change. See Google’s guidance on debugging performance in the field.
Rank #4
What to investigate for each metric
LCP: identify the actual largest element and its timing
Do not treat a slow LCP number as a diagnosis. Capture which element was the LCP candidate and investigate the timing components that contributed to its render. The candidate can differ by visitor because viewport, scroll position, and personalized content vary. Use field attribution rather than assuming one element is responsible for every visit.
INP: locate the slow interaction phase
Reproduce the slow interaction and use DevTools traces together with field attribution. The delay may occur before event handlers run (input delay), while handlers execute (processing time), or as the browser renders the next frame (presentation delay). Attribution can expose the interaction target and type along with phase timings; Long Animation Frames data can add diagnostic context in supported environments. Google’s guide to finding slow interactions describes this field-debugging approach.
A page-load Lighthouse audit without user input does not measure INP. Total Blocking Time (TBT) can help diagnose main-thread blocking in a lab, but it is a proxy in this context—not an INP measurement and not calculated in the same way.
CLS: test after load and reserve space
Layout shifts can happen after the initial load, including when users scroll or interact. Test real flows and inspect field attribution for the elements involved. Reserve space for images and video with dimensions or CSS aspect-ratio; content that arrives late without reserved space can move other content.
A load-only lab pass can miss interaction-dependent or later shifts. In addition, JavaScript measurement cannot capture every shift inside iframes, while CrUX may include iframe shifts. Account for that difference when comparing your own measurements with CrUX. Google’s CLS guidance covers common shift causes and improvements.
Why field and Lighthouse results differ
Field and lab measurements describe different conditions. Field data reflects real visits across devices, networks, viewports, page content, and interactions; a lab run is a controlled observation of a particular test setup. A Lighthouse score is useful for diagnosis and regression checks, but it is not a complete account of user experience. It may not run the interactions that expose a slow INP or later CLS, and TBT should not be labeled as INP.
Use a lab result to investigate a suspected cause and field distributions to determine whether real visitors benefit from a change. Do not infer a real-world improvement from a single Lighthouse run alone.
Quick Recap
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.
