The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Only partly, and the answer depends on the browser and the tool you measure with. A single-page app should not assume that its field numbers already include every in-app navigation. The status and what to do about it are covered in the single-page app section below.
What the three metrics measure and what “good” means
Core Web Vitals are three user-experience metrics that Google’s Web Vitals guidance groups into loading, responsiveness, and visual stability. Each one has a “good” threshold, and each is judged at a specific statistical point.
As an Amazon Associate I earn from qualifying purchases.
| Metric | What it captures | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | How long the largest visible content element takes to render during loading | ≤ 2.5 seconds (2,500 ms) |
| Interaction to Next Paint (INP) | Responsiveness: the delay between a user’s click, tap, or key press and the next visual update, summarized across the visit | ≤ 200 ms |
| Cumulative Layout Shift (CLS) | Unexpected movement of visible content while the page is in use | ≤ 0.1 |
These thresholds come from Google’s web.dev Web Vitals guidance, as updated in 2024. Google recommends evaluating each metric at the 75th percentile and segmenting results by mobile and desktop. A page meets the threshold when at least 75% of its visits are at or below it. Averages hide the problem: a blended figure can look healthy while one device class fails. Consider a hypothetical site where the mobile 75th-percentile LCP is 3.1 seconds and the desktop value is 1.8 seconds. The desktop number looks fine, but mobile visitors need work, and only the split view shows that.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Field data and lab data answer different questions
Field data records what real visitors experienced. Lab data comes from a controlled test on one configured device, network, and location. Both are useful, and they answer different questions.
#1 Best Overall
| Approach | Typical sources | Best for | Limitation |
|---|---|---|---|
| Field (real users) | CrUX-based views such as the field section of PageSpeed Insights and the Search Console Core Web Vitals report; a real-user monitoring (RUM) setup built with the web-vitals library | Judging actual visitor experience and trends over time | Aggregated and delayed. Pages with little traffic may have no field data at all. |
| Lab (controlled) | Lighthouse in Chrome DevTools, Lighthouse CI, WebPageTest | Reproducing and diagnosing an issue, and checking changes before release | Reflects only the device, network, and location you configure, and cannot capture real user interactions |
Lab and field numbers often differ because devices, networks, visitor locations, content, caching, and interactions all differ between the two. A single Lighthouse run is therefore a diagnostic snapshot, not a verdict on what your visitors experience.
A measurement workflow you can repeat
- Start with field evidence for the templates that matter. In Search Console, open the Core Web Vitals report (in current versions it sits under the Experience section of the left-hand menu). In PageSpeed Insights, enter a URL and read the field data at the top of the report.
- Split by device. Compare the 75th-percentile values for mobile and desktop separately against the thresholds in the table above.
- Reproduce the problem in the lab. In Chrome, open DevTools (F12 on Windows and Linux, or Cmd+Option+I on macOS), choose the Lighthouse tab, select Mobile or Desktop, and click Analyze page load. The report identifies the LCP element and lists diagnostics for the other metrics.
- Recreate your audience’s conditions. WebPageTest lets you choose a test location and a connection profile. Run tests from the regions where your visitors are, using a mobile profile if most of your traffic is mobile.
- Re-check field data after the fix. CrUX data is a rolling aggregate, so improvements show up gradually rather than on the day you deploy.
The measurement guide on web.dev, Getting started with measuring Web Vitals, describes these approaches in more detail.
Which tool does what
| Tool | Data type | Use it for |
|---|---|---|
| Chrome DevTools (Performance, Network, and Coverage panels) | Lab | Finding long tasks, slow requests, redirect chains, and unused code |
| PageSpeed Insights | Field where available, plus a lab run | A combined view of a single URL |
| Search Console Core Web Vitals report | Field | Spotting site-wide patterns across groups of URLs |
| Lighthouse and Lighthouse CI | Lab | Repeatable audits, and regression checks inside a build pipeline |
| WebPageTest | Lab | Testing from chosen locations, devices, and connection speeds |
| web-vitals JavaScript library | Field, from your own visitors | Sending real metric values from your site to your analytics |
The tools above are developer tools, not commercial RUM services. Collecting metrics from your own visitors requires either the web-vitals library or a RUM service of your choice, and the lab tools cannot substitute for that.
Why INP needs more than a lab run
INP reflects the interactions a visitor actually makes: taps, clicks, and key presses. A non-interactive lab run does not perform those interactions, so INP cannot be read directly from one. Google identifies Total Blocking Time (TBT) as a lab proxy for this problem, not as an equivalent metric. TBT flags main-thread work that could delay input, which makes it a good place to look first. The measurement guide linked above explains the distinction. Confirm the real INP with interaction-aware measurement from your visitors.
import { onINP } from 'web-vitals';
onINP(metric => console.log(metric.name, metric.value, metric.rating));The snippet above logs INP values for each page view. Send the values to your analytics endpoint instead of the console once you have confirmed the data looks right.
Fixing the right problem first
Improvements should follow diagnosis. Start with the metric that fails, on the page template that carries the most traffic, and weigh each change’s implementation effort against its likely effect on users. Google’s guide to improving Core Web Vitals, The most effective ways to improve Core Web Vitals, favors realistic work with broad real-world impact over applying every optimization to every page.
Largest Contentful Paint
Google’s optimization guide, last updated in 2024, attributes to Chrome UX Report data the finding that 40% of sites do not meet the recommended good LCP threshold. Treat that figure as a sector-wide indicator, not a benchmark for your own site.
Recommended Free Tools
- Identify the LCP element first. Lighthouse reports it, and the Performance panel in DevTools shows it during a page load.
- Make the LCP resource discoverable early. An image written into the HTML is found sooner than one that appears only after a script runs.
- Prioritize that one resource. Setting
fetchpriority='high'on the LCP image tells the browser to fetch it first. Userel='preload'only for resources the browser would otherwise discover late, because preloading too many files competes with the resources that matter. - Do not lazy-load the image that is the LCP element.
- Reduce the time before the first byte arrives, which is covered in the hosting section below.
Interaction to Next Paint
- Reduce unneeded JavaScript. Open the Command Menu (Ctrl+Shift+P, or Cmd+Shift+P on macOS), choose Show Coverage, and check how much of each script runs on a typical page.
- Split non-critical code so features that users do not need immediately are loaded later.
- Break long tasks into smaller pieces and yield back to the main thread between them, so pending input can be handled.
- Avoid expensive rendering updates inside a single event handler, such as rebuilding a large section of the DOM on every click.
Cumulative Layout Shift
- Reserve space for images, video, embeds, and ad slots, using width and height attributes or the CSS aspect-ratio property.
- Reserve space for content that loads late, such as banners, consent prompts, and related-content modules, instead of inserting it above content the visitor is already reading.
- Animate with transform and opacity rather than properties that change layout, such as top, width, or height.
Hosting location, TTFB, and CDNs
Hosting affects speed partly through geography and caching. Time to First Byte (TTFB) measures how long the browser waits before the first byte of the response arrives. A distant origin server can raise TTFB. Because every later step of a page load depends on that first response, a slow TTFB can also delay the LCP resource. Hosting is not the whole picture, however. Rendering, client-side JavaScript, images, and layout can be the limiting factors even when the server responds quickly, so changing hosts alone will not fix every Core Web Vital.
Checking the server path
- Compare your audience with your origin. Use your analytics to see which countries or regions generate most visits, and note where your origin server is hosted.
- Test from those regions. Run WebPageTest from the audience’s region with a mobile connection profile, and read the TTFB value in the waterfall.
- Check caching. In Chrome DevTools, open the Network panel, click a document or asset request, and inspect the Headers tab for Cache-Control and related headers. Reload the page and check whether repeat responses come from cache.
- Count redirects. Each redirect adds a round trip before the final page starts to load. In the Network panel, a chain of 301 or 302 responses appears as several rows ahead of the document.
What a CDN changes
A content delivery network (CDN) stores copies of your content on servers closer to visitors. For cacheable responses, such as static files and pages that can be cached, that shortens the distance the content travels. Responses generated separately for each visitor generally still need to reach the origin, so a CDN helps most where caching is set up correctly.
A CDN is sometimes included in a hosting plan, but what you receive varies by provider and tier. Before deciding, check:
- Which regions have edge coverage relative to your audience
- Which cache rules you can configure, and how cache purging works after a deployment
- Whether the CDN is included at your plan tier or is an add-on
- How your application’s cache headers are honored at the edge
Single-page apps and route transitions
A single-page app (SPA) loads its application shell once and then updates the view with JavaScript as the visitor moves between routes. A multi-page app (MPA) loads a new document for each page. The practical question is whether Core Web Vitals reflect what visitors experience during in-app navigations.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Google’s position on architecture
Google’s guidance does not favor one architecture. Its FAQ on SPA architectures states: “Google does not have any preference as to what architecture or technology is used to build a site.” The same FAQ says SPAs and MPAs can both deliver high-quality experiences, and that the metrics aim to measure experience independently of the technology used to build the site. The FAQ is How SPA architectures affect Core Web Vitals.
Best Value
Where route-transition measurement stands
The FAQ, updated August 11, 2026, reports the following status:
- Chrome 151 introduced APIs for measuring Core Web Vitals across SPA route transitions.
- Tool adoption of those APIs was beginning at the time of the update.
- No date for CrUX integration had been published, so CrUX-based field numbers should not yet be assumed to include route transitions.
- As of the update, other browser engines did not support those APIs, so the new measurement reaches Chrome visitors only.
Because this is a snapshot of a changing area, check Google’s FAQ for later updates before relying on any of these points.
Quick Recap
Measuring a SPA now
- Check your visitors’ browsers. Your analytics browser report shows how much of your traffic runs on Chrome 151 or later, which is the only group the new APIs reach as of the update.
- Confirm RUM support. Read your RUM library’s documentation to see whether it uses the route-transition APIs before treating its numbers as complete.
- Test important routes separately. Lab runs usually load a URL directly. To examine an in-app navigation, record it in the DevTools Performance panel while you click through the route.
- Find out how your field tool groups URLs. If several routes share one URL, aggregated numbers blend them together.
Architecture trade-offs to compare
- The actual experience on your most important routes, on mobile and desktop
- Implementation constraints, including your team’s skills and the existing stack
- Caching behavior for each architecture’s HTML, scripts, and data responses
- Measurement support for the browsers your audience uses
Troubleshooting common mismatches
| Symptom | Likely area | First check |
|---|---|---|
| Lab LCP passes, but field LCP fails on mobile | The device, network, or location in your test differs from your visitors’ | Split field data by device, then rerun WebPageTest with a mobile profile from the region where slow visits come from |
| Field INP fails, but lab TBT looks acceptable | The lab run has no interactions, so slow handlers never ran | Use the web-vitals library to identify the interaction type, then profile that interaction in the DevTools Performance panel |
| TTFB is high only for distant visitors | Origin distance, missing caching, or limited CDN coverage | Compare origin location with audience regions, inspect Cache-Control headers, and check edge coverage |
| CLS fails after the page loads | Content inserted above existing content, or media without reserved space | Record a load in the Performance panel and look for layout shift markers |
| LCP and INP look fine on first load, but single-page app routes feel slow | In-app navigations may not be captured by your current field measurement | Test each route in the lab, and confirm your RUM setup and visitors’ browsers against the SPA section above |
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.
Free tools Windows power users keep installed
One-click scans. No signup required.
