Your site passed the speed test, but customers are still waiting: lab tests versus real user measurements

The owner of a small online shop runs a speed test on her website, sees a green score and breathes a sigh of relief. A week later, a customer calls to complain that a particular product page "freezes" on her phone. Both are right. The tool tested one thing, the customer experienced another, and the difference is one of the most important concepts a website owner can understand: the distinction between lab data and field data.

Two types of measurement, two different questions

Lab data is the result of a simulated test: software loads a page once, on one device, at a predetermined network speed, and measures what happened. The best-known tool of this kind is Google's Lighthouse, which produces the score from 0 to 100 many people recognise from PageSpeed Insights.

Field data answers a completely different question: what real people experienced when they visited the site. Google collects this data from Chrome users who agreed to share it, in a report called the Chrome User Experience Report, or CrUX. According to the official PageSpeed Insights documentation, the field data displayed there covers the past 28 days.

Put simply, the lab answers "How does this page behave under particular conditions?" and the field answers "What did this page feel like to my customers?" Both questions matter, but they are not the same question.

Why a green score and a customer's complaint can both be right

A lab test checks one page load. In the mobile test, according to Google's documentation, Lighthouse simulates a mid-range phone on a mobile network, and the test runs from servers in North America, Europe or Asia. Your customers, by contrast, browse on a five-year-old phone with a weak 4G connection on a train, a new laptop on fibre broadband, or a tablet with twenty tabs open. Each will have a different experience.

There are also things a lab test simply cannot see. It does not click buttons, open menus or fill in forms. Nor does it always see what changes between visitors: a cookie banner appearing only on a first visit, personalised content or an advertisement that loads late. Meanwhile, the score itself is not completely stable: PageSpeed Insights documentation explicitly notes that it can vary between runs even without any page changes, because of network and hardware conditions.

The three metrics Google wants you to know

Google defines three central user experience metrics, collectively called Core Web Vitals. According to the definitions published on Google's web.dev site:

• LCP (Largest Contentful Paint): the time until the largest element in the visible part of the page, usually a main image or heading, appears. Good: up to 2.5 seconds.
• INP (Interaction to Next Paint): how quickly the page responds to clicks, taps or typing. Good: up to 200 milliseconds. This metric replaced the previous one, FID, in 2024.
• CLS (Cumulative Layout Shift): how much content jumps around as the page loads, for example when a button moves just before you click it. Good: up to 0.1.

An important detail many people miss: assessment uses the 75th percentile of visits, separately for mobile and desktop. In other words, for a page to be considered "good," at least three out of four visits must meet the threshold. A page that is very fast for most visitors but very slow for a quarter of them still does not pass.

There is a small catch here: INP cannot be measured in a lab test because there is no user clicking anything. Lighthouse instead uses an indirect metric called Total Blocking Time. Someone looking only at the lab score may therefore completely miss a page that loads quickly but responds slowly.

What to do when there is no field data at all

For small or new websites, PageSpeed Insights sometimes says there is not enough real user data. According to the documentation, when a particular page lacks enough samples, the tool switches to data for the whole site, and when the whole site also lacks enough data, no field data is shown. That does not mean the site is bad. It only means there is not enough traffic from Chrome users to calculate a reliable average.

In that situation, the lab test is the main tool remaining, and should be used wisely: run it several times and look at the trend rather than a single run, test the pages most important to the business, such as the homepage, a product page and the contact page, rather than only the homepage, and also test on a real phone, preferably not the newest, over a mobile connection. Larger organisations install their own real user monitoring, which web.dev describes as the way to obtain page-level detail that public data does not provide.

Deciding what to fix first without chasing numbers

The most common mistake is treating the score as the goal. A lab score of 100 does not guarantee happy customers, and 70 does not mean a site is broken. A reasonable order of priorities looks roughly like this: first examine field data, if available, and identify which of the three metrics misses the threshold. Then use the lab test to understand why, because that is where detailed recommendations appear. Finally, make changes, wait and check again, knowing field data moves slowly because it is based on a 28-day window.

Be wary of promises too. No technical change guarantees higher Google rankings or sales, and anyone promising this with certainty is selling more than measurement can deliver. What can be said confidently is that a page that loads quickly, responds immediately and does not jump around is easier to use, and that this is what these metrics are designed to reflect. Anyone wanting to explore each metric, understand a test report and compare their own site's values with the thresholds can find guides to measuring website performance in Hebrew alongside free tools that run in the browser.

The right question is not "What was the score?" but "What did people experience?"

Back to the shop owner: her green score did not lie. It simply answered a different question from her customer's. A lab test is like a test drive on an empty road on a Saturday morning, while field data is every driver's journeys during rush hour. Anyone wanting to know how customers really experience a site needs both: the lab to find the fault, and the field to know whether the fix actually reached the people the site exists to serve.