Field Data or Lab Data: Which Core Web Vitals Number Should You Fix First?

Should you fix your field data or your lab data first?

Field data decides what to fix. Lab data helps you fix it. Those are two different jobs, and using the wrong one for the wrong job is the most common reason performance work produces no visible result. Priorities come from real users. Debugging happens in the controlled environment.

The confusion is understandable because both are labelled Core Web Vitals and both show you the same three metric names. Google's documentation on why the two can differ is blunt about the cause: lab and field data actually measure very different things, so a disagreement between them is expected rather than a bug in one of the tools.

I run into this on almost every performance conversation. Someone has a green Lighthouse score and a failing Search Console report, or the reverse, and assumes one of the tools is wrong. Neither is. They are answering different questions.

What is lab data actually measuring?

One page load under conditions you chose. Google describes lab data as being determined by loading a page in a controlled environment with a predefined set of network and device conditions, and notes that Chrome tools reporting lab data are generally running Lighthouse. The point is reproducibility, not realism.

The documentation spells out the shape of the test in a way worth memorising: a lab test consists of a single device, connected to a single network, run from a single geographic location. Every source of variance in the real world has been deliberately removed so that two runs give you comparable numbers.

That design makes lab data excellent for one thing and unreliable for another. It is excellent for comparing before and after on the same page, because everything except your change is held constant. It is unreliable as a verdict on user experience, because the specific conditions chosen may look nothing like your actual audience.

What is field data actually measuring?

Every real visit, as a distribution. Google describes field data as monitoring all users who visit a page and measuring performance for each of those individual experiences, reflecting their actual devices, network conditions, and geographic locations. It also notes that field data and real user monitoring are interchangeable terms.

The critical property is one people skip past. Google says the most important thing to understand about field data is that it is not just one number, it is a distribution of numbers. Some visitors have a fast experience, some have a slow one, and the field data for your site is all of it together.

Chrome tools generally get field data from the Chrome User Experience Report, and Google notes that CrUX reports show a distribution of metrics from real Chrome users over a 28-day period. That window matters when you deploy a fix and wonder why nothing moved by Friday.

Why do the two numbers disagree so dramatically?

Because field data includes everything lab data excludes. Google lists the sorts of factors a lab test drops: the variance across networks, device capabilities, and geographic locations, plus real user behaviour like scrolling, selecting text, and tapping elements, plus browser optimisations such as the back and forward cache.

Google's own example in that documentation makes the gap concrete. In the field distribution shown, 88 percent of visits saw a largest contentful paint of 2.5 seconds or less, 8 percent were between 2.5 and 4 seconds, and 4 percent were worse than 4 seconds. At the 75th percentile the value was 1.8 seconds. The lab test of the same page returned 3.0 seconds.

Google's comment on that discrepancy is the part I quote to clients. The lab value is still a valid measurement for that page. It is simply one of many values making up the full distribution of load experiences, and it happened to land on the slower side of it.

What does the 75th percentile actually mean for your priorities?

It means you are being scored on your unlucky quarter, not your average. Google states that tools reporting Core Web Vitals field scores do so using the 75th percentile, so your median visitor could be having a fine time while your score reflects the experience of the slowest quarter of your traffic.

This changes what counts as a good fix. A change that makes fast visits slightly faster does almost nothing to a 75th percentile score. A change that rescues the worst visits, typically on mid range mobile hardware or poor connections, moves it immediately. Optimising for your own laptop is the classic way to work hard and move nothing.

It also tells you where to look for causes. If your distribution has a long tail, the interesting question is what those visitors have in common, not what your homepage does on fibre. Geography, device class, and logged-in state are the three splits I check first.

Which thresholds are you actually aiming at?

Google publishes them plainly. For a good user experience it recommends largest contentful paint occurring within the first 2.5 seconds of the page starting to load, interaction to next paint below 200 milliseconds, and a cumulative layout shift score below 0.1. Those apply at the 75th percentile of field data.

Google frames the reason for caring in terms of Search as well as users. Its documentation says it highly recommends site owners achieve good Core Web Vitals for success with Search and for a good user experience generally, and that this aligns with what its core ranking systems seek to reward.

Note the phrasing there, because it is doing careful work. Aligning with what ranking systems seek to reward is not the same as a direct ranking multiplier, and I would not promise a client rankings from a performance project on the strength of that sentence.

Why does the LCP element differ between the two tools?

Because the largest element on screen depends on who is looking. Google notes that a Lighthouse run returns the same LCP element every time, while field data for the same page usually shows a variety of LCP elements depending on circumstances specific to each visit.

The factors it lists are worth checking against your own site. Different screen sizes change which elements are inside the viewport. Logged-in or personalised content can change the element entirely. A running A/B test can display very different elements. Even the fonts installed on a user's system affect text size, and therefore which element is largest.

There is one more that catches Webflow blogs specifically. Google points out that lab tests usually run against a page's base URL without query parameters or fragments, while real users often arrive on URLs containing a fragment identifier or a text fragment. If most of your traffic lands mid page from an AI answer or a search result, your real LCP element may be one you have never optimised.

So what is the working order for a real site?

Start in Search Console's Core Web Vitals report to find which page groups are failing in the field. Then reproduce one failing URL in Lighthouse to get a debuggable trace. Then fix, then re-test in the lab for a fast signal, then wait for the field data to confirm it across the 28-day window.

The step people skip is the reproduction. If a page fails in the field and passes in the lab, your default lab conditions are not representative, so change them until the failure appears. Throttle harder, switch to a mobile profile, test the URL shape your users actually arrive on. A failure you cannot reproduce is a failure you cannot debug.

Grouping matters more than individual URLs on a CMS site, because a Webflow blog with hundreds of posts has a handful of templates and one performance profile per template. I made that argument at length in setting per-template Core Web Vitals budgets in Webflow, and it remains the single biggest time saver on large sites.

What should you not conclude from a green lab score?

That you are done. A green Lighthouse result means one simulated visit on one device over one network went well. It is evidence, and it is the weakest evidence available about what your users experience, because it deliberately removed the variation that creates your 75th percentile.

The inverse error is equally common and more demoralising. A red lab score on a page whose field data is fine is not an emergency. Google's example shows exactly that situation, with a 3.0 second lab value sitting inside a distribution whose 75th percentile was 1.8 seconds. Fix the field failures first and treat the lab number as a debugging instrument.

The metric where I make an exception is interaction to next paint, because lab tools cannot see real interaction patterns at all. That one genuinely needs field measurement, and I went through the practical side in optimising INP on Webflow. Delivery and caching choices affect the tail too, which I covered in edge cache headers and Core Web Vitals on Webflow.

What should you do next?

Open the Core Web Vitals report in Search Console before you open any testing tool, and write down which page groups fail and on which metric. That list is your actual priority order, and it is usually shorter and different from the one a lab audit would have produced.

Then take the single worst group, reproduce the failure in the lab under conditions that match your real users, and fix that one thing. Wait out the field window before judging the result, because a 28-day rolling distribution does not reward impatience. If you want someone to read your field data and tell you which of the findings is worth your week, reach out with your domain.