What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
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
To improve Web Vitals, pair field measurements from real visits with controlled browser debugging: use field data to identify which pages and visitors are affected, reproduce the problem with Lighthouse or Chrome DevTools, make a targeted change, and then check whether field distributions improve. The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google’s Web Vitals guidance recommends that at least 75% of page loads meet the “good” thresholds, evaluated separately for mobile and desktop: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1.
What Web Vitals measure—and what “good” means
Each Core Web Vital describes a different aspect of a visitor’s experience. LCP measures loading, INP measures responsiveness to interactions, and CLS measures visual stability. The recommended thresholds are not a promise that every visit will meet a target; they are a way to assess a distribution of visits. Google recommends comparing the 75th percentile for mobile and desktop separately.
| Metric | Experience measured | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the largest visible content element is rendered | At or below 2.5 seconds |
| Interaction to Next Paint (INP) | Responsiveness: the delay from a user interaction until the next visual update | At or below 200 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability: unexpected movement of visible content | At or below 0.1 |
These thresholds and the 75th-percentile evaluation guidance are published by Google/web.dev. Check the official documentation for the current metric set and guidance, as Web Vitals can evolve.
Choose the right tool for the question
Field and lab measurements answer different questions. Field data shows outcomes from actual visits, while a lab run or browser trace helps you investigate under controlled conditions. Neither is a substitute for the other.
#1 Best Overall
| Approach | Best use | What it cannot tell you alone |
|---|---|---|
| CrUX, PageSpeed Insights, or Search Console field data | Check aggregated real-user outcomes and whether a problem exists | Often lacks per-pageview detail needed to identify a specific element or interaction; availability depends on the source and page population. |
Site-owned RUM with web-vitals |
Track your own visits, page-level distributions, and attribution signals | Requires instrumentation and backend reporting; JavaScript measurement has edge cases, including iframe shifts. |
| Lighthouse | Repeatable lab diagnosis and pre-release regression checks | A page-load run without interaction cannot measure INP, and can miss interaction-dependent CLS. |
| Chrome DevTools Performance panel | Inspect runtime behavior and record interactions on a page | A local trace is not a population-level field distribution. |
Use PageSpeed Insights, Search Console, or CrUX for an initial field view. Aggregated field data can reveal whether a population is having trouble, but it generally does not show the exact pageview-level cause. Add site-owned real-user monitoring (RUM) when you need timely, detailed observations from your own visits. Google’s measurement introduction explains the roles of field and lab tools.
Establish a field baseline
Before changing code, record a baseline that lets you see which parts of the experience are affected. Report percentiles and useful segments, not just averages: averages can conceal a poor experience for a meaningful share of visits. Compare mobile and desktop separately, and segment by page type when that distinction helps locate the problem.
Rank #2
- Record the metric name, value, and a stable metric identifier for each observation.
- Include only page and device dimensions that help diagnose performance; avoid collecting unnecessary personal data.
- Use the 75th percentile when comparing results with Google’s recommended thresholds.
- Note which field source produced the data. Aggregate sources may not expose the same detail as site-owned RUM.
For attribution signals and field collection practices, see web.dev’s field-measurement guidance.
Collect LCP, INP, and CLS with JavaScript
The web-vitals library provides callbacks for the three metrics. This minimal example sends each reported metric to an analytics endpoint, using navigator.sendBeacon() when available and a keepalive fetch as a fallback:
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);Adapt the endpoint and configure corresponding custom metrics or events in your analytics backend if that system requires it. Keep the measurement code asynchronous and lightweight. A heavy bundle loaded early or expensive work inside a callback can compete with rendering and user input, distorting the performance you intend to measure. The web.dev Web Vitals documentation describes the JavaScript library and collection approach.
Diagnose LCP, INP, and CLS in the browser
Find what is delaying LCP
Run a repeatable Lighthouse audit or record the page in Chrome DevTools under representative device and network conditions. Identify the actual LCP candidate and inspect the time components contributing to its rendering; the final LCP value is an outcome, not an explanation by itself. The candidate may differ among visitors because viewport size, scroll position, or personalized content changes what is visible. Capture the candidate from visits rather than assuming one element is always responsible.
Rank #4
Trace the interaction behind slow INP
Use field attribution to find the affected interaction, then reproduce its click, tap, or keyboard action in DevTools. Inspect the trace to determine whether time was spent waiting before handlers ran, executing event-handler code, or rendering the next frame. This distinction matters: shortening a handler will not address delay that occurs before the handler starts or during the browser’s presentation work.
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 →Attribution can include the interaction target and type, along with phase timings. Long Animation Frames data can provide additional diagnostic context where the browser supports it. web.dev’s guide to finding slow interactions in the field covers how to move from field observations to a specific interaction.
Reproduce shifts that occur after load
Test real user flows and post-load states, not only the initial page load. Lazy-loaded content, scrolling, hover states, and interaction-driven updates can cause shifts later. Reserve space for images and video by specifying dimensions or applying CSS aspect-ratio; content that arrives without reserved space can push other content around.
JavaScript field measurements do not capture every shift inside an iframe, while CrUX may include iframe shifts. That difference can help explain why in-page measurements and aggregate field data do not match. See web.dev’s field-debugging guidance and its CLS optimization guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify fixes in the lab and in the field
- Recheck the controlled case. Run the same Lighthouse audit or DevTools trace before and after the change, using comparable device and network conditions. Confirm that the intended page state or interaction improved and that another relevant behavior did not regress.
- Observe real visits. Track field distributions after release. Compare the affected page type and device segments with the baseline rather than relying on a single lab score.
- Judge the outcome at the right percentile. Check whether the 75th-percentile result for mobile or desktop moved toward the applicable good threshold.
A lab result can confirm a controlled change, but it cannot by itself prove that real visitors improved. Field conditions vary, so use lab traces to diagnose and field distributions to validate the outcome. The distinction between those measurements is covered in Google’s guide to measuring Web Vitals.
Recommended Free Tools
Quick Recap
Common measurement mistakes
- Treating a Lighthouse score as the whole experience. Lab and field conditions differ, and a page-load audit may not exercise interactions or later layout changes.
- Calling Total Blocking Time (TBT) an INP measurement. TBT is a lab metric that can help identify main-thread blocking. It is not INP; without user input, it is only a diagnostic proxy for responsiveness.
- Reporting only averages. Averages can hide variation among visits. Use percentiles and relevant segments.
- Letting measurement code affect the result. Avoid a heavy early-loaded RUM bundle and expensive callback work; keep collection non-blocking.
- Assuming one LCP element applies to every visit. Viewport, scroll position, and personalized content can change the candidate.
- Assuming CLS ends when the page finishes loading. Exercise scrolling and interactions, and inspect shifts that occur later.
- Assuming page JavaScript captures every iframe shift. CrUX may include shifts that in-page JavaScript cannot observe, so the two sources can differ.
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.
