Field Data Over Lab Scores: Measure Real Shop Speed

A shop can show a clean number in a testing tool and still feel slow - and the other way round. The reason is rarely a measurement error; it is usually a mix-up of two kinds of data. A lab run measures one page under fixed conditions, while field data collects what actually reaches visitors. Both numbers can be correct, they simply answer different questions. This article shows how the two kinds of measurement come about, why the 75th percentile is the decisive figure in the field, what the limits of the public Chrome dataset are, and in what order your own collection and PageSpeed optimisation fit together.

Lab and field do not measure the same thing

A lab value comes from loading a page in a controlled environment: one defined device, one defined network connection, one defined location (web.dev). A field value comes about differently - it records what actually happened for each individual visitor and assembles a distribution from it (web.dev). The difference sounds academic, but it decides what a number can carry as a statement. A lab run is repeatable and therefore useful for comparing two states of the same page. A field value is not repeatable, but it describes the reality in which orders are placed or abandoned. Playing the two against each other means losing the benefit of both. Which three metrics are meant here and how they come about is set out in our overview of Core Web Vitals.

The most important sentence about field data is the one most often skipped: it is not a single number but a distribution of numbers (web.dev). On the same product page one visitor loads over fibre in the office in less than a second, a second one on a train over a fluctuating mobile connection in eight seconds, and a third returns and gets the page from the cache almost without waiting. All three experiences belong to the same address. A tool that turns this into one number has picked a point out of that distribution - and the real question is which one. This is exactly where the confusion starts that keeps showing up in reports as a contradiction: two tools quote different numbers for the same page, although both measured cleanly.

The most important thing to understand about field data is that it is not just one number, it's a distribution of numbers.

Philip Walton, web.dev: Why lab and field data can be different

For work on a shop this leads to a division of labour. The lab run belongs in development: it shows repeatably whether a change makes an image load later, blocks a script for longer or requests an additional typeface. The field value belongs in the assessment: it says whether the change reaches the people who actually order. A high score in a testing tool is therefore not a result but an interim state - what striving for perfect scores does in everyday practice is described in our article on Lighthouse top scores in Shopware. Conversely, a weak field value is hard to fix without a lab run, because it lacks the repeatability you need to track down the cause.

The 75th percentile is not an average

Tools that report Core Web Vitals from the field evaluate them at the 75th percentile (web.dev). That is neither an average nor a median: it is the value that three out of four page views reached or beat. The choice has a rationale. A median would leave half of all visitors out of account, while a very high percentile would be driven by a few outliers - with a hundred page views, five outliers are enough to tip the 95th percentile (web.dev). The 75th percentile balances both: the majority of page views are covered, and individual disruptions do not determine the result. This choice applies to all three metrics alike.

This construction leads to a rule that is often missing in practice: a page counts as good when at least 75 percent of page views meet the good threshold (web.dev). A single very slow page view changes nothing about that, whereas a quarter of slow page views certainly does. Anyone setting a target should therefore phrase it at exactly this point - not as a wish for a fast page, but as a statement about the share of page views that should meet a given threshold. The thresholds themselves and how they were derived are described in more detail in our introduction to Core Web Vitals.

For a shop this has a practical consequence. The distribution is rarely symmetrical: the bulk of page views sits on the left, and a long tail to the right is created by weak devices, poor connections and cold caches. Looking at the average gives you a number that hardly any visitor experiences. Looking at the 75th percentile gives you the line beyond which it becomes uncomfortable for a quarter of page views - and that is the group in which abandonments happen. It is therefore worth looking at the distribution itself, not only at the one number a tool derives from it.

• How many page views sit behind the number - with a small population the percentile fluctuates strongly.
• How far mobile and desktop are apart - throwing both groups together usually hides the problem.
• Which page types are included - home, category, product and checkout pages behave differently.
• Whether returning visitors are included - a warm cache lifts the result without anything having improved.
• Which period was evaluated - a week with a campaign looks different from a quiet month.

What the public Chrome dataset shows and what it does not

The publicly available field source is the Chrome User Experience Report. It is based on a rolling window of 28 days, and this period cannot be changed (web.dev). Anyone who ships a change on Monday and checks the public data on Friday is therefore largely looking at the time before it. Only after roughly four weeks is the window fully filled with the new state. This inertia is not a flaw but the condition for the number staying comparable across millions of websites - it does, however, make the source unsuitable for proving an effect the day after a release.

On top of that come limits in the population. The dataset contains Chrome users only (web.dev); Chrome on iOS does not count, because a different rendering engine works there, and neither do Android apps with an embedded web view (Chrome UX Report). Only users who have opted in to usage statistic reporting and who sync their browsing history are recorded (Chrome UX Report). A page also has to be publicly discoverable and sufficiently popular, otherwise it does not appear at all (Chrome UX Report). For many shops this means there are values for the domain but not for the individual product page. Anyone who wants more precision cannot avoid their own collection - how that works without a third-party service is shown in our article on server-side tracking on your own infrastructure.

• Chrome only: other browsers and Chrome on iOS contribute nothing to the dataset (Chrome UX Report).
• Opted-in users only: collection requires usage statistic reporting to be enabled and browsing history to be synced without a separate passphrase (Chrome UX Report).
• Discoverable pages only: an address with noindex or a status code other than 200 drops out (Chrome UX Report).
• Sufficiently visited pages only: below an unpublished threshold neither the page nor the domain appears (Chrome UX Report).
• Parameters are dropped: query strings and fragments are stripped from the address, so different variants end up together (Chrome UX Report).
• Embedded frames count towards the parent page: a frame does not appear separately, but its layout shifts affect the surrounding page (Chrome UX Report).

The field figures from the July 2025 dataset

So what does the field look like? In the July 2025 dataset evaluated by the Web Almanac 2025, 48 % of mobile websites pass all three Core Web Vitals - after 44 % the year before and 36 % two years before (Web Almanac 2025). On desktop the share is 56 %, after 55 % the year before, so the gain there was small (Web Almanac 2025). The gap between the two device categories is stubborn and has an obvious cause: slower networks and weaker devices. For a shop this means that an evaluation without a split by device category gives away a substantial part of the statement. Where your own shop sits in this distribution can be established with a shop check.

The individual metrics show the same pattern more clearly. For Largest Contentful Paint, 74 % of desktop pages reach a good value and 62 % on mobile; the share of poor experiences on mobile stands at 13 %, close to double the desktop figure of 7 % (Web Almanac 2025). This is not a fringe problem: when more than half of a shop's traffic comes from phones, the mobile distribution decides the overall result - and the revenue that is lost at the weakest point.

One of the most revealing figures concerns page type. Home pages pass at 47 % on desktop and 45 % on mobile, while secondary pages reach 61 % and 56 % (Web Almanac 2025). The reason is well known: the home page carries hero images, campaign areas and embeds that a product page does without. For the evaluation this means that a single value for the whole domain distorts the picture - depending on how traffic is spread across page types. A clean evaluation also involves filtering out automated traffic; how bots and scrapers can be recognised and steered out is described in our article on bot traffic in an online shop.

Why the lab value is still needed

Despite all its limits the lab run stays necessary, and the numbers show why. Total Blocking Time, a pure lab metric, sits in the HTTP Archive lab crawl of July 2025 at the 75th percentile per page at 336 milliseconds on desktop and at 4,193 milliseconds on mobile (Web Almanac 2025). The median value on mobile rose there to 1,916 milliseconds, an increase of 58 % over 1,209 milliseconds the year before (Web Almanac 2025). At the same time responsiveness in the field is improving. This apparent contradiction can be explained: the lab metric measures the blocking during loading under controlled conditions, while the field metric measures the response at the moment a person actually taps - and people usually tap only once the page looks finished. The lab metric is therefore used explicitly as a proxy for the responsiveness figure that can only come from real user data (Web Almanac 2025).

The second reason is practical. A change can only be defended if its effect becomes visible before release, and that requires fixed conditions. This is exactly what a lab run delivers: device, connection and location stay the same, so that the difference between two states falls back on the change and not on the time of day in the mobile network. The prerequisite is an environment close to production without holding customer data - how such an environment can be set up is described in our article on staging with test data instead of customer data.

Why the two numbers for the same page drift apart can be named. In the lab the same element is regularly identified as the largest; in the field, screen size, sign-in state, running experiments and the available fonts decide which element is largest (web.dev). The lab run starts with an empty cache, while some real visitors already hold parts of the page (web.dev). Back navigations through the history list are counted in the field and are almost instantaneous, whereas they do not occur in the lab (web.dev). And observation of the largest element ends in the field as soon as a person scrolls or taps, whereas in the lab it ends only with the complete load (web.dev). Each of these points shifts the number in a particular direction - taken together they explain a large share of the deviations that are argued about in reports.

This gives a division of labour that has proved itself in projects: the lab run happens with every change and reports regressions before they go live. Field data runs continuously and decides what gets worked on next. Anyone observing both together with availability also recognises whether a drop is caused by their own code or by the environment; how such an observation system can be built is shown in our article on shop monitoring for uptime and performance.

Collecting your own field data without a third-party service

Collecting your own field data takes less effort than the term suggests. The browsers deliver the necessary events themselves; what is needed is a small collector in the browser, an endpoint on your own domain and an evaluation that calculates percentiles. No third-party service and usually no additional consent dialogue, as long as no personal attributes are stored. How measurement data can be collected without cookies on your own infrastructure is described in our article on server-side tracking. The decisive difference from the public dataset: you record all browsers, all pages and any period you need.

// Field collection without a third-party service: own endpoint, own evaluation
const buffer = [];

function report(name, value) {
  buffer.push({ name, value: Math.round(value), path: location.pathname });
}

// Largest contentful element: the last entry counts
new PerformanceObserver((list) => {
  const entries = list.getEntries();
  report('LCP', entries[entries.length - 1].startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });

// Sum up layout shifts without recent input
let shift = 0;
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) shift += entry.value;
  }
}).observe({ type: 'layout-shift', buffered: true });

// Slowest interaction as an approximation for INP
let slowest = 0;
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.interactionId && entry.duration > slowest) {
      slowest = entry.duration;
    }
  }
}).observe({ type: 'event', durationThreshold: 40, buffered: true });

// Only send on leaving, so the value is complete
addEventListener('visibilitychange', () => {
  if (document.visibilityState !== 'hidden') return;
  report('CLS', shift * 1000); // in thousandths, to keep it an integer
  report('INP', slowest);
  navigator.sendBeacon('/api/fielddata', JSON.stringify(buffer));
}, { once: true });

When storing the data, segmentation matters more than volume. A value without additional attributes is hardly usable; only with page type, device category, connection class, country and the question of whether this is a first or a returning visit does it become a basis for decisions. The count matters just as much: percentiles from a few hundred page views fluctuate so strongly that they mislead rather than help. Anyone taking a sample should record the sampling rate and take it into account when comparing, otherwise a change to the collection turns into an apparent improvement. For the integration into an existing application we draw on our own development work.

• Metric and value, in whole milliseconds or thousandths
• Page type: home, category, product, cart, checkout
• Device category and screen width at the time of the page view
• First or returning visit, so that warm caches stay visible
• Origin of the page view, split into search, ads, referral and direct entry
• Date and hour, so that campaign periods can be filtered out

From measured value to decision

Measured values only turn into a decision once the order is settled. It follows not from the size of the shortfall alone, but from the interplay of shortfall and weight: a category page carrying a quarter of the traffic weighs more than a fringe page with the same shortfall. The following order has proved itself in projects and can be set up in an afternoon.

1. Record traffic per page type and identify the three page types that together carry most of the page views.
2. Look at the distribution for those page types, split by mobile and desktop, and note the 75th percentile.
3. Determine the gap to the good threshold per metric and weight it by the share of traffic.
4. Reproduce the largest weighted gap in the lab until the cause appears repeatably.
5. Ship the change and record the lab value before and after.
6. After four full weeks, evaluate the field distribution again and hold the result against the expectation.

Responsiveness deserves a separate look, because it behaves differently from the loading impression: it arises not during loading but during tapping, and therefore affects filters, cart and checkout above all. A shop can look good on the loading impression and still feel sluggish at the checkout. Where the causes lie and which interventions typically pay off is collected in our article on improving responsiveness.

What this means in everyday shop operations

In everyday shop operations the difference shows up at three points in particular. First, during campaigns: a campaign brings traffic from devices and networks that otherwise barely occur; the field distribution widens without anything on the page having changed. Second, with extensions: an additional module in the page header shifts the lab value by a few points and the field distribution by considerably more, because it hits weak devices harder. Third, during catalogue rebuilds: a new filter logic can leave the loading impression untouched and still make responsiveness worse. Anyone planning such interventions should set up the collection beforehand - our Shopware development sets it up as part of the project.

Part of the spread does not originate in the code but in the environment. Server response times, caches, image delivery and connectivity act directly on the first visible content and therefore on the whole distribution. These shares are hard to judge with lab runs, because the conditions there are either ideal or artificially throttled. In ongoing support we therefore look at field data and server logs together; what that involves is set out on our page about hosting and operations.

That leaves the question of which number belongs in the report to management. In our experience a single score rarely carries far there: it fluctuates, it cannot be tied to revenue, and it invites the follow-up question about a perfect score. More robust is a statement about shares - how many page views on the highest-revenue page types meet the good threshold, split by mobile and desktop, with a reference date and a count. This form survives the next change of tooling, because it is not tied to a tool but to the distribution itself.

How we approach this

We start with a stocktake: which field sources exist, how the collection is built in, and which page types carry the traffic. After that we set up your own collection on your infrastructure, check it for plausibility against the public dataset and lay out the evaluation by segment. On this basis the order of work emerges, each step with a lab value before and after the change and a follow-up measurement in the field after four full weeks. If you would like to know how your shop actually stands in the field, get in touch with us.