PageSpeed Looks Good but Core Web Vitals Fail? Lab vs Field Data Explained

The “PageSpeed good Core Web Vitals fail” pattern is more common than most site owners expect. A good test score can be misleading. You fix a page, run a test, see a strong score, and assume the work is done. Then the real-visitor assessment still shows a fail, and you are left wondering whether the fix helped at all, or whether the test was wrong.

Neither result is necessarily wrong. They are measuring different things, in different conditions, from different visitors. This guide explains that difference — the classic PageSpeed good Core Web Vitals fail case — so you can stop chasing one score and start diagnosing the right problem. It is a focused diagnostic post, not a second Core Web Vitals guide. For the full explanation of loading, interaction, and layout stability, use the Core Web Vitals guide linked below.

What is the difference between lab data and field data?

Lab data comes from a controlled test. A tool loads your page once, in a simulated environment, with a set device, connection, and location, and records what happened during that single load. It is repeatable, which makes it useful for finding problems and comparing changes. If you change one thing and test again in the same lab conditions, you can see whether that change helped in that test.

Field data comes from real visitors. It is collected from people who actually visited your page, on their own devices, connections, and locations, over a period of time. It reflects the messy reality of real use: different phones, different networks, different times of day, and different ways of interacting with the page. It is not a single test, it is an aggregate of many real visits.

That difference explains most disagreements. A lab test shows what can happen in one controlled load. Field data shows what usually happens for real visitors. Both are useful, but they answer different questions. Lab data is best for diagnosis, field data is best for judging the real visitor experience. Google’s guide on why lab and field data can be different explains each cause in detail.

The Core Web Vitals guide for WordPress at https://prospeedguy.com/wordpress-core-web-vitals-guide/ explains loading, interaction, and layout stability in plain terms, and how the three metrics work together.

Why can one page pass in the lab and fail for real visitors: a PageSpeed good Core Web Vitals fail case

A page can pass in the lab and fail in the field for several ordinary reasons, none of which means the lab test lied. The first reason is device and connection. A lab test may simulate a mid-range phone and a fast connection, while many real visitors use slower phones, weaker connections, or both. A page that a lab device handles easily can still strain a slower real phone.

The second reason is interaction. A lab test usually loads a page and records what happens during load. Real visitors also scroll, tap, type, open menus, and add items to a cart. Interaction problems, especially slow responses to taps and clicks, often appear only after load, when a visitor actually uses the page. A lab load test can miss that entirely.

The third reason is timing. A lab test captures one moment, often on a fast server at a quiet time. Real visitors arrive at all hours, including busy periods, and their experience includes server load, third-party scripts, advertising, and other services that may behave differently at different times. A page that is fast in a quiet lab test can be slower for visitors during a busy period.

The fourth reason is content that changes. A page with personalised content, dynamic pricing, location-based offers, or logged-in features will behave differently for different visitors. A lab test sees one version of the page, while field data aggregates many versions. If one common version is slow, the field assessment can fail even when the lab version passed.

Should I trust URL data or origin data?

Field data can be reported at two levels, and knowing which one you are looking at matters. URL data is for one specific page, such as your homepage or one product page. Origin data is for your whole site, aggregated across many pages on the same domain.

URL data is more useful when it exists, because it tells you about the exact page you are trying to fix. If your homepage has URL data, use that to judge the homepage. Origin data can hide a problem on one page, because fast pages can balance out slow pages in the aggregate, or a slow page can drag down an otherwise healthy site average.

Origin data is still useful, especially when a page does not have enough real visits on its own to produce URL data. It gives you a site-wide picture and can show whether a problem is isolated to one page or widespread. Use origin data as a starting point, then drill down to URL data for the pages that matter most, such as the homepage, key landing pages, and checkout pages.

For a comparison of the tools themselves, the PageSpeed Insights versus GTmetrix guide at https://prospeedguy.com/pagespeed-insights-vs-gtmetrix/ explains what each tool measures and where each one is most useful.

Why does one page have field data and another page does not?

Not every page gets field data. Field data depends on real visitors, and a page needs enough real visits, from enough different visitors, to produce a reliable aggregate. A popular homepage or a busy product page will usually have field data. A new post, a rarely visited page, or a page that only a small group sees may not.

This is normal, and it is not a sign that something is broken. It simply means there is not yet enough real-visitor evidence to judge that page. In that case, use lab data to find and fix problems on that page, and use origin data to understand the site-wide picture. As the page gains more real visits, its own field data may appear.

If a report seems stuck or out of date, the Core Web Vitals report not updating guide at https://prospeedguy.com/core-web-vitals-report-not-updating/ explains why a report can lag behind recent changes, and what to check before assuming the work did not help.

How long does it take for a fix to show in field data?

A fix does not show in field data immediately, and you should not expect it to. Field data is an aggregate over a period of time, not a snapshot of today. When you fix a page, new visits after the fix will gradually replace older visits in that aggregate. Until enough new visits have accumulated, the old, slower visits still influence the result.

How long that takes depends on how much traffic the page gets. A busy page, with many visits every day, will refresh its field picture much faster than a quiet page with only a few visits. A page that is rarely visited may take a long time to show a change, even if the fix itself was effective. That is a property of the data, not proof that the fix failed.

Do not state a fixed waiting period as a guarantee, and do not promise a client or yourself that field data will pass by a particular date. Instead, keep a record of when the fix went live, keep testing in the lab to confirm the fix is still in place, and check field data periodically. If lab tests show the problem is fixed, and the fix has been live for a reasonable period with real traffic, field data should gradually move in the right direction. If it does not, that is a signal to investigate further, not to assume the lab test was wrong.

Which pages should I test first?

Start with the pages that matter most to visitors and to the business, not with every page at once. For most sites, that means the homepage first, because it is the most visited page and the first impression for many visitors. Next, test the key landing pages that receive traffic from search or advertising, and the pages where visitors convert, such as product pages, service pages, and checkout pages.

For a store, test product pages and checkout separately, because they behave very differently. A product page is mostly about images, layout, and interaction, while checkout is a dynamic, uncacheable page with payment and shipping checks. A fix that helps one may not help the other, so test them as separate problems.

The WooCommerce speed test guide at https://prospeedguy.com/woocommerce-speed-test/ explains how to test store pages in a way that matches how shoppers actually use them, rather than testing only the homepage and assuming the rest of the store behaves the same way.

What do I do when lab and field disagree?

When lab and field disagree, treat the disagreement as a clue, not as a contradiction to resolve by picking one side. Start by confirming the basics. Are you looking at the same page, in both reports? Is one report URL data and the other origin data? Is the lab test recent, and does the live page, as a logged-out visitor, actually contain the fix you made?

Next, use lab data to diagnose. Run a lab test, look at the largest problems it reports, and fix the clearest ones first. Focus on the first screen, on interaction delays, and on layout shift, because those are the problems visitors notice most. Test after each change, on staging first, and keep a backup before changing a live site.

Then, check field data again over time, not immediately after the fix. If lab tests show the problem is fixed, and field data gradually improves, the work is on track. If lab tests show the problem is fixed but field data does not move at all, look for a reason real visitors are not seeing the fix, such as caching, a different page version, or a problem that only appears for real visitors, such as interaction delays or third-party scripts that behave differently in real use.

Finally, keep a simple checklist for each important page, so you do not have to start from scratch every time. The WordPress speed audit checklist at https://prospeedguy.com/wordpress-speed-audit-checklist/ gives a structured way to work through hosting, images, scripts, caching, and layout, page by page, without guessing.

If you have worked through the checks above and still cannot explain the disagreement, or if the problem involves hosting, scripts, and interaction at the same time, a free speed audit can help you get a clear, prioritised list of what to fix first.

Common Questions

Frequently Asked Questions

Short answers to the questions readers ask most about lab and field data.