Core Web Vitals and page experience guide

What do field and lab data each show?

Field data is a record of real visits; lab data is a controlled experiment. PageSpeed Insights says lab data is "useful for debugging issues" but "may not capture real-world bottlenecks", while field data captures "true, real-world user experience" but "has a more limited set of metrics". Its field figures come from the Chrome User Experience Report (CrUX) over "the previous 28-day collection period"; its lab figures come from Lighthouse simulating a mid-tier phone on a mobile network, or an emulated desktop on a wired connection.

Three metrics make up the Core Web Vitals. Values between the two thresholds are labelled needs improvement.

Most reports skip the 75th-percentile rule. web.dev recommends measuring "the 75th percentile of page loads, segmented across mobile and desktop devices": a page passes on a device type only when three visits in four were within the threshold. The slowest quarter is left out, so a passing page can still keep some visitors waiting, and a failing page may have had a fine median visit.

Lab and field also disagree for structural reasons. Lighthouse loads a page without any user interaction, so it cannot measure INP and reports Total Blocking Time as a stand-in. Lab tools see only shifts that happen during loading, so web.dev notes that lab CLS "may be less than what real users experience in the field", where late widgets and banners still move content.

What this has to do with ranking

Google's own wording is qualified and worth quoting. Its page experience documentation says "Core Web Vitals are used by our ranking systems" and recommends that site owners "achieve good Core Web Vitals for success with Search". It also says "Google Search always seeks to show the most relevant content, even if the page experience is sub-par", that "there is no single signal", and that page experience aspects beyond Core Web Vitals "don't directly help your website rank higher". A slower page that answers the query better can outrank a faster one; fixing a poor metric removes a disadvantage, and nothing here promises it will move a ranking.

Which users and templates are represented?

Only some visitors and pages are counted, and pages are reported in groups. Users: CrUX reflects "how real-world Chrome users experience popular destinations on the web". It counts Chrome users who enable usage statistic reporting, sync their browser history, have no sync passphrase, and use desktop Chrome or Chrome on Android. Chrome on iOS, Android WebView apps and other Chromium browsers such as Microsoft Edge are excluded, and Safari is not Chrome at all. If your customers skew towards iPhones, the field data describes a different crowd, and your interpretation must say so.

Pages: CrUX states that "not all origins or pages are represented in the dataset". A page must be publicly discoverable, defined as returning HTTP 200 with no noindex header or meta tag, and "sufficiently popular", a minimum number of visitors that Google does not publish. When a URL falls short, PageSpeed Insights falls back to origin-level data covering "all user experiences on all pages of the website"; when the origin falls short too, it shows no field data. For a modest-traffic site that is a limit of measurement, not a clean bill of health. Pages kept out of the index are outside the field data too, so check your robots, noindex and canonical controls first.

Groups and templates: the Search Console report groups URLs into "pages that have a similar user experience", gives each group "the slowest status assigned to it for that device type", shows "a sample of pages" rather than every URL, and needs "a minimum amount of data" before a group appears. In practice a URL group is a template: product page, blog post, location page. Diagnosis therefore starts at the group, and one template fix repairs every URL that shares it.

Device and network: CrUX reports a form factor of phone, tablet or desktop "inferred from the device User-Agent string", and Search Console splits its report the same way. The Effective Connection Type dimension was removed in February 2025 and replaced by a round-trip time (RTT) metric, so network context is now a latency figure. Read the phone split first for a Malaysian consumer business: a connection that feels quick in a city office can crawl in a lift or a crowded mall, and the 75th percentile exists to capture that slower quarter. We put no numbers on this; read your own origin's RTT and form-factor figures.

How should a poor metric be investigated?

Work from the group to the template to the element, and confirm the cause in the lab before anyone changes code. The score comes last.

1. 1

   Start in Search Console, not in a score

   Open the Core Web Vitals report, mobile view first, note which group is poor on which metric, then open it for the sample URLs. With no data, pick a representative URL yourself.

2. 2

   Confirm the group is one template

   Open three or four sample URLs. If they share a layout, investigate the template as a possible common cause, then test whether shared code, content or third-party scripts explain the issue; if not, split them by layout.

3. 3

   Read the field figure before the score

   Run one sample URL through PageSpeed Insights. Record whether the field data is URL-level or an origin fallback, the 75th-percentile value against its threshold, and the phone versus desktop split.

4. 4

   Reproduce it in the lab under field-like conditions

   Run the mobile lab test and read the diagnostics: the LCP element, the shifting elements, the long tasks. If the lab is kinder than the field, repeat in DevTools on a slower network profile with a phone viewport, performing the taps a visitor would.

5. 5

   Name the cause and the owner

   Use the matrix to turn the observation into a likely cause, a confirming test and an owner, and write all four down. A finding without a test is still a guess.

6. 6

   Fix the template, then validate over a full window

   Re-run the lab test the same day to confirm the mechanism changed, then start validation in Search Console, which treats the issue as fixed only if it is "not present in any URLs on your site during the 28-day window". Report that field result.

The matrix is our own working list, drawn from the causes web.dev documents and from patterns common on small-business sites; it starts a diagnosis and does not replace the confirming test.

Which fix belongs to the website owner?

Ownership follows the cause, not the tool that reported it. A report names a metric, the matrix names a mechanism, and the mechanism belongs to whoever controls it: typically four people, often at different firms.

• Hosting owns server response time, caching and where the server sits relative to your visitors; a slow time to first byte on every page is a hosting conversation first.
• Developer owns how the template loads and behaves: the weight and order of scripts and styles, responsive image rules, width and height attributes, what runs on tap and click, how third-party code loads.
• Designer owns the choices behind the mechanisms: a full-screen video hero on a page visited mostly from phones, custom fonts without a fallback plan, layouts with no room reserved for a late banner or widget.
• Content and marketing own what is added after launch: embedded videos, review widgets, chat tools, booking iframes, tag-manager scripts, camera-sized images. In our experience these are the commonest reason a site that passed at launch fails later.

The website owner's job is to hold the evidence, not to fix the code: ask each party for the confirming test rather than a promise, decline a fix that cannot name the metric and template it will change, and report the outcome from the field figure after a full window. Our technical SEO service is built around this handoff.

Two things this page deliberately does not do. It does not treat a passing assessment as a ranking outcome: Google's wording is qualified, and search performance depends far more on whether pages answer the tasks people search for, as the search visibility overview explains. And it is not an accessibility audit: Core Web Vitals say nothing about whether a page works with a screen reader or a keyboard, and compliance with any accessibility standard is separate work. A complete SEO audit puts performance beside crawlability, indexing and content; guides on rendering and user-experience implementation will follow on the hub.

What to do next

1. 1Open the Core Web Vitals report in Search Console, mobile view first, and write down each poor group, its metric and its sample URLs.
2. 2Run one sample URL from each poor group through PageSpeed Insights and record the field value against its threshold before looking at the score.
3. 3Fill in one matrix row per group and send it to its owner with the test, not the score.
4. 4After a fix, start validation in Search Console, set a review date 28 days out, and report the field result on that date.