Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides 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 pass Core Web Vitals, a page must meet all three good thresholds at the 75th percentile of real visits: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Check mobile and desktop separately. A Lighthouse score can help diagnose problems, but it is not the field-based pass assessment.
What counts as passing Core Web Vitals?
Google’s current Core Web Vitals are three measures of loading, responsiveness, and visual stability. A page passes when all three are in the good range at the 75th percentile of page visits. In practical terms, at least 75% of measured visits must meet each metric’s good threshold. Assess mobile and desktop segments separately; the thresholds are the same for both.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the largest visible image, text block, or video renders | 2.5 seconds or less | More than 2.5 seconds through 4 seconds | More than 4 seconds |
| Interaction to Next Paint (INP) | Responsiveness to user interactions | 200 milliseconds or less | More than 200 milliseconds through 500 milliseconds | More than 500 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability: unexpected layout movement | 0.1 or less | More than 0.1 through 0.25 | More than 0.25 |
Thresholds are from Google’s Core Web Vitals threshold guidance, updated May 7, 2025. A single metric outside the good range means the page does not pass, even if its other two metrics are good. Values between the good and poor thresholds need improvement.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to check whether a page passes
Start with field data: it reflects real visits, rather than one controlled test. Google’s measurement guide describes how to use CrUX-based reports and diagnostic tools; these sources provide different views and are not interchangeable.
#1 Best Overall
- Used Book in Good Condition
- Check PageSpeed Insights. Enter the page URL and review the field data section. Note whether the result is URL-level or origin-level and whether it represents mobile or desktop. The report uses Chrome User Experience Report (CrUX) data aggregated over the past 28 days. A URL-level result concerns that page; an origin-level result describes eligible pages across the site’s origin and may not match the specific URL.
- Check Search Console for affected page groups. Open the Core Web Vitals report for a verified property to see groups of URLs with similar issues and follow their historical patterns. It helps identify scope, but it is not a view of every individual visit.
- Use first-party real-user monitoring if you need more detail. Instrumentation, optionally with Google’s
web-vitalslibrary, can give your team more timely and detailed feedback about its own users. It requires you to collect and report the measurements. - Reproduce the problem with a lab tool. Use Chrome DevTools’ Performance panel to inspect a trace, or run Lighthouse or WebPageTest under controlled conditions. A local trace can help explain a problem, but it does not replace the real-user distribution.
What if PageSpeed Insights has no field data?
Missing field data means there is not enough available CrUX evidence for that URL or origin in the report. It proves neither a pass nor a failure. Use available origin or Search Console data as context, and consider first-party monitoring if you need measurements for your own traffic.
Why do lab and field results differ?
Lab tests run under specific device, network, location, and content conditions. Real visits vary: users may have different devices and connections, encounter redirects or different cache states, or receive personalized content. As a result, a good Lighthouse run does not guarantee that field data passes, and a poor lab run alone does not establish that the field assessment fails.
Rank #2
How to fix the metric that is failing
Use a repeatable loop: identify the failing metric and affected page or template in field data, investigate likely causes with diagnostics, make a targeted change, and check real-user results again. This is a measurement workflow, not a guarantee that any one change will fix a particular site.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
If LCP is too high
LCP is the render time of the largest visible image, text block, or video, measured relative to navigation. An oversized or slow-loading image may be involved, but it is not always the whole problem. Field LCP can also include time spent unloading the previous page, establishing a connection, following redirects, or waiting for the server to respond. Inspect the trace and the page’s actual loading path before choosing a fix.
Rank #3
If INP is too high
INP measures responsiveness to user interactions across visits. First establish which pages or device segments are affected and investigate the interaction using real-user data and available traces. The threshold establishes how responsive the experience must be; it does not, by itself, identify a universal implementation change. Verify any targeted change against field results rather than assuming that one code adjustment will improve every site.
If CLS is too high
CLS captures the largest session window of unexpected layout shifts over a page’s lifecycle. Common sources include images or videos without known dimensions, fonts that render at a different size than their fallback, and ads or widgets that resize dynamically. Check the production experience as well as local tests: cached assets, personalization, and API timing can make a shift appear inconsistently.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why the assessment uses the 75th percentile
The 75th percentile is intended to represent the experience of most visits without letting outliers dominate the result. Google says its threshold methodology balances user experience with achievability on existing websites, drawing on human-perception research where available and CrUX data to check that good thresholds can be attained. The same targets apply on mobile and desktop, though the devices and networks people use differ.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →The official thresholds define how an assessment works; they do not establish a current percentage of all websites that pass. A site’s result depends on its own field data and should be read for the relevant URL or origin and device segment.
Quick Recap
Best Value
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.
