Why Is Your Site Fast in the Lab and Slow for Real Users?

The audit came back close to perfect. That same week somebody in sales said the site takes forever on their phone at a client’s office, and a support ticket described a form that "does not respond" on an older Android handset. Every one of those reports is accurate. They are measurements of different things, and treating them as one number is how a month of performance work gets spent in the wrong place.

Lab data is a controlled reconstruction: one device profile, one network profile, one page, usually a cold cache, usually no consent decision, usually nobody signed in. Field data is what actually happened to the people who visited, on whatever hardware they were holding, wherever they happened to be standing. The lab tells you whether a page is capable of being fast. The field tells you whether it was.

The gap between the two is not noise and it is not a defect in either tool. It has four main sources: the device, the network, the state of the cache, and everything a third party loaded after the audit finished. This piece walks each one, then sets out the measurement setup we would insist on before anybody spends a day on technical SEO or on optimisation of any kind.

Two numbers, two different questions

A lab run is reproducible and attributable. Change one image, run it again, see the difference. That property makes it excellent for catching regressions and useless for describing your audience, because reproducibility is purchased by removing everything that varies, and everything that varies is exactly what your visitors are made of.

Field data has the opposite shape. It is representative and slow. You cannot ask it why, only what, and you have to wait for enough sessions before the answer stabilises. In that sense it behaves like any lagging indicator: by the time the number moves, the cause is weeks behind you. Use both, but never let one of them answer the other one’s question.

The device gap

JavaScript costs are paid in processor time, and processor time is not evenly distributed across your audience. The same bundle that parses and executes in a blink on a recent laptop takes many times longer on a mid-range phone that is three years old, warm in a pocket, and already running four other applications. Nothing about the page changed. The machine executing it did.

Two effects compound this and neither shows up in a lab run. Phones throttle when they get hot, so the second minute of a session is slower than the first. And background work competes for the same single main thread that your interaction handlers need, which is why a page can finish loading quickly and still feel unresponsive to a tap for another second afterwards.

Your phone is not the median device

Development teams carry good hardware, and they test on it, and it produces a consistent and gentle picture of the world. The fix is unglamorous: keep one deliberately unimpressive Android phone in the office, put it on mobile data rather than the office network, and make it the device that signs off a release. It will change design decisions before it changes code. This is the same argument as any build or buy question: the cost you cannot see at the point of decision is the one that gets paid later, by somebody else.

The network gap

Most throttling profiles reduce bandwidth. Real mobile networks mostly hurt through latency, and latency punishes a completely different kind of mistake. Bandwidth limits how much you can send; latency limits how many times you can take turns. A page that needs a round trip for the HTML, another for a redirect, another to resolve a font host, another to negotiate a connection to a script provider and another before that script requests the thing it actually wanted has spent its budget on conversation rather than content.

Then there is geography. A single origin server sitting one continent away adds a fixed toll to every uncached request, and no amount of image compression will remove it. Corporate proxies inspect and re-encrypt traffic. Hotel and conference networks are shared and lossy. None of this is your code being bad. All of it lands in your field data.

The cache gap nobody segments

Lab tests run cold by default, because a cold run is the reproducible one. Real traffic is a mixture, and the ratio is a property of your audience rather than your site. A publication whose readers return weekly will show a field number better than any cold lab run. A service page that receives mostly first-time arrivals from search will show one that is worse, and that page is precisely the one you spent money to be found on.

Deployment resets this. Fingerprinted assets change filename on every release, so an active publishing schedule keeps a share of your audience permanently on a cold cache. It is a genuine trade, and it is one of the ongoing costs people forget to price when they estimate what it costs to maintain what they built.

The practical instruction is short. Never compare an aggregate field number to a lab number. Split the field data by new and returning visitors first, then compare the new-visitor segment to your cold lab run. Those two are measuring roughly the same event, and the difference that remains is signal.

The third parties the audit never loaded

This is the biggest and least discussed source of divergence, and it has a simple mechanism. An automated audit usually arrives with no consent decision recorded. Your consent banner therefore blocks the marketing tags, the chat widget, the session recorder, the advertising pixels and the personalisation script. The tool measures a version of the page that no consenting human ever receives.

Run the audit twice, once with consent refused and once with consent granted, and the difference between the two runs is the price of your marketing stack. Teams are routinely surprised. Nobody added all of it at once; it arrived one tag at a time, each addition individually defensible, none of them ever removed.

The scripts you agreed to block on

A particular category deserves naming: scripts you deliberately let block rendering. Experimentation tools that hide the page until a variant is chosen, personalisation that waits for a decision, and font loaders configured to hold text back rather than swap. Each was a considered choice. Together they mean the visitor stares at a blank area while three vendors negotiate. Client-rendered templates make it worse, because the shell arrives fast and the content does not, which is one of the trades you accept in headless commerce and in any architecture that assembles the page in the browser.

Every third-party script is a promise that somebody else’s bad day will become your slow page.

The measurement setup that tells the truth

None of the above is fixable while the only evidence is a score from a tool run by hand on a laptop. This is the setup we would put in place first, and it is mostly configuration rather than engineering. It belongs with the rest of your analytics and measurement rather than in a separate performance project that ends when the invoice does.

1. Collect field measurements from your own pages. Load timing and interaction latency, reported from real sessions, tagged with the template name. Public aggregate data is a useful sanity check and far too coarse to act on.
2. Report a high percentile, never an average. Averages hide the tail, and the tail is the entire subject. The people having the worst experience are the ones deciding whether to come back.
3. Segment before you interpret. By template, device class, country, connection type, and new against returning. A single site-wide number is an average of unrelated things and will point you somewhere false.
4. Keep one pinned lab test in the release pipeline. Fixed device profile, fixed network profile, fixed set of URLs, failing the build on a defined regression. Its job is comparison over time, not describing reality.
5. Run every audit twice on consent. Once refused, once granted. Publish both numbers side by side so nobody quotes the flattering one in a status update.
6. Test the pages that matter, not the homepage. The search landing page, the product page, the form, the signed-in view. Homepages are the most optimised and least visited page on most sites.
7. Set a budget and attach it to review. A number for script weight and one for main-thread time, checked when something is added rather than six months later. Budgets only work when they can refuse a change.

Reading the disagreement instead of arguing about it

Once both data sets exist, the shape of their disagreement is itself a diagnosis. These patterns come up repeatedly and each points somewhere specific.

• Lab good, field bad, mostly on Android. Script execution cost. You are shipping more JavaScript than the median device can afford, and no image work will touch it.
• Lab good, field bad, everywhere. Something loads only in real sessions. Start with the consent-gated tags and the experimentation script.
• Lab bad, field acceptable. A returning, cache-warm audience is flattering you. Fix it anyway, because first-time arrivals are the ones you paid to acquire.
• Both bad, one template only. A genuine regression with a small blast radius, and the cheapest kind to find. Check what changed on that template last.
• Field bad in one country only. Distance to the origin, or an edge network that does not cover that region. Infrastructure, not code.
• Load fine, interaction slow. Main-thread work after the page appears. Usually hydration, an oversized listener, or a script doing layout work on scroll.

What turns this from a spreadsheet into action is severity and order. A raw list of measurements invites everyone to pick the item they already wanted to work on. Tooling that resolves observations into findings with a severity, a priority and a recommendation, which is what Prooflin produces, is more useful at this point than another dashboard, because the argument you are about to have is about sequence rather than facts.

Where we would start, and when the lab wins

Fix what appears in both data sets first. Anything the lab flags that the field confirms is real, reproducible and attributable, which makes it the cheapest work available. Then take the field-only problems in order of how much traffic sits behind them, and accept that some of those will be answered with infrastructure or with removing a vendor rather than with code.

Here is the concession, and it reverses the advice. Before launch you have no field data at all, and pretending otherwise wastes months. In that window the lab number is the only number, and it is a perfectly good one to build against, provided the profile you test with resembles the audience you expect rather than the machine you own. The same applies to a rebuilt template with no traffic yet. Lab-first is right when there is no field to consult; it becomes wrong the moment there is, and teams keep optimising against the reconstruction long after real people arrived. Choosing the build that fits the audience is a decision made at that point, not after launch.

One more thing worth saying without hedging. Performance is not a project, because it decays. Every release adds a script, every campaign adds a tag, every quarter adds a vendor, and the page that was fast in March is ordinary by September without anyone doing anything wrong. The only version of this that holds is a budget with the authority to refuse an addition, plus a number somebody looks at on a schedule.

If your audit score and your visitors disagree and you want help working out which of the four gaps is doing it, tell us what you measured and on what.