Field data vs lab scores: measuring a store honestly
Gencer KarakayaFounder & Shopify Engineer
Published · 6 min read
Short answer
Lab data, such as a Lighthouse score in PageSpeed Insights, comes from one simulated page load on fixed device and network settings. Field data comes from real visitors: Shopify’s web performance reports show the 75th percentile of LCP, INP and CLS, with a summary of the past 30 days, and Google’s CrUX data covers 28 days. Use field data to judge the store and lab data to find causes.
- Lab data comes from a page loaded in a controlled environment with a predefined device and network; field data comes from real users’ visits.
- Shopify’s web performance reports show LCP, INP and CLS at the 75th percentile from real user data; the summary covers the past 30 days, and reports can be filtered by device type.
- PageSpeed Insights field data covers the previous 28-day collection period; its performance score comes from a Lighthouse lab run and varies between runs.
- Good Core Web Vitals thresholds are LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile.
- Lab tools such as Lighthouse can’t measure INP because there is no user input; Total Blocking Time is the lab proxy.
Ask three tools how fast a Shopify store is and you can get three answers. PageSpeed Insights shows a score out of 100, the Shopify admin shows milliseconds, Search Console shows groups of URLs marked good or poor. They are not contradicting each other: they measure different things. Knowing which is which is the difference between fixing the store and chasing a number.
Two kinds of numbers
Lab data comes from loading a page in a controlled environment, with a predefined device and network. Lighthouse produces it, and it is what the score at the top of PageSpeed Insights is based on. It is repeatable enough to debug with, and it shows *why* a page is slow: which script blocks rendering, which image is the largest element.
Field data comes from real visitors, each on their own phone, connection and cache. Google calls this real user monitoring. It can’t tell you why a page is slow, but it is the only data that says how the store actually performed for the people who shop on it.
Why the two disagree
Google’s web.dev guidance lists the reasons. The ones that matter most on a store:
- Caching. A lab test loads the page with a cold cache. Returning shoppers often have your theme’s CSS and scripts cached already.
- The largest element changes. The element that counts for LCP can differ by screen size, personalization or an A/B test.
- Real interaction. A lab run doesn’t click a variant picker or open a cart drawer. Field data captures what happens when people do.
- Scrolling. Layout shifts from lazy-loaded images happen when a visitor scrolls; a lab load may never trigger them.
- One device versus many. A lab test is a single simulated load. Field data is a distribution across every device and connection your visitors use.
Where each number comes from on a Shopify store
| Tool | Kind | What it reports | Watch for |
|---|---|---|---|
| Shopify web performance reports | Field | LCP, INP and CLS at the 75th percentile from real user data, with a 30-day summary, filters for device type, and reports by page type and URL. Over-time charts carry numbered markers for changes such as app installs, theme updates and new code | Data can be delayed by up to 36 hours and is kept for 90 days. A new store, or one in private mode, may have no metrics |
| PageSpeed Insights, field section | Field (CrUX) | Real-user metrics for the URL over the previous 28-day collection period | Without enough data for the URL, it falls back to the whole origin, which mixes every page type |
| PageSpeed Insights, performance score | Lab (Lighthouse) | A score from a simulated load: 90 and above is good, 50 to 89 needs improvement, below 50 is poor | The score varies between runs with network availability, hardware and resource contention |
| Search Console, Core Web Vitals report | Field (CrUX) | URLs grouped by similar experience, rated good, needs improvement or poor | Groups without enough data are left out or folded into an origin group; validating a fix starts a 28-day monitoring session |
CrUX, the dataset behind PageSpeed Insights’ field section and Search Console, has its own limits. It only includes pages that are publicly discoverable and have enough visitors, and it collects from Chrome users on desktop and Android who have opted in. Chrome on iOS is not included, so iPhone shoppers are missing from it. Shopify’s reports draw on a broader set of browsers, all Chromium browsers and Firefox, though Safari isn’t included there either, and they can be broken down by page type. That makes them the better first stop for a Shopify store.
The thresholds that matter
Google’s Core Web Vitals are three field metrics, each judged at the 75th percentile of page loads, separately for mobile and desktop:
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading | 2.5 s or less | Over 4 s |
| INP (Interaction to Next Paint) | Responsiveness | 200 ms or less | Over 500 ms |
| CLS (Cumulative Layout Shift) | Visual stability | 0.1 or less | Over 0.25 |
INP needs a real person to interact, so lab tools can’t measure it. Lighthouse reports Total Blocking Time instead, a proxy for how busy the main thread is. A good TBT in the lab is a hint, not proof, that INP will be good in the field.
What lab data is still good for
None of this makes lab tools useless. Field data tells you that product pages are slow on mobile; it can’t tell you why. Lighthouse and the browser’s performance panel can:
- Identifying the LCP element on a template, so you know which image or heading to prioritize.
- Finding render-blocking scripts and stylesheets, including those added by apps.
- Spotting long main-thread tasks, the usual suspects behind poor responsiveness, through Total Blocking Time.
- Catching regressions before release. Testing an unpublished theme or a new app in the lab is the only way to see its effect before real visitors do.
The rule of thumb: field data decides whether there is a problem and whether it is fixed; lab data decides where to look. A lab score that improves while field data stays flat means the change didn’t reach real visitors, or didn’t matter to them.
A routine for measuring a change
- Start from the field. Read Shopify’s web performance reports, filtered by device type. A problem on mobile can hide behind a good desktop figure, and the other way round.
- Name the metric and the template. “The store is slow” can’t be fixed. “Mobile LCP on product pages” can, and Shopify’s page type reports show which template is behind a slow metric.
- Use lab tools to find the cause. Run Lighthouse on a representative URL of that template, several times, and look at the diagnostics rather than the score: render-blocking scripts, the LCP element, long main-thread tasks.
- Change one thing, and write down when. Shopify’s over-time reports mark changes such as app installs and theme updates; note your own changes too, with the date, so a movement in the field data can be tied to a cause.
- Wait for the window to roll. Shopify’s summary covers 30 days and CrUX 28, so a fix shows up gradually, not the next morning. Compare the same device type and template before and after.
- Report both, labelled. “Mobile LCP p75 on product pages, Shopify web performance reports, 30 days” is a claim someone can check. “We scored 94” is not.
Common reporting traps
- Quoting one Lighthouse run. It is a single simulated load and it moves between runs. A before-and-after based on two single runs proves little.
- Reading origin data as page data. When PageSpeed Insights falls back to origin-level field data, the number describes the whole site, not the page you tested.
- Optimizing the homepage only. Measure the templates that carry your traffic, usually collection and product pages as well as the homepage.
- Treating the score as the goal. The score is a lab diagnostic. The Core Web Vitals, measured on real visits, are what describe the experience.
How this shapes performance work
Lintel’s performance and technical SEO work follows the same order: field data first, lab tools to trace each problem to an app, a script, an image or the theme, then a fix at the source and a second measurement. When the cause is theme code or a script an app adds to the theme, the fix is theme engineering.
Questions
- Why is my PageSpeed Insights score low when Shopify’s performance reports look fine?
- They measure different things. The score comes from one simulated Lighthouse load on fixed device and network settings. Shopify’s reports show what real visitors experienced, summarised over the past 30 days at the 75th percentile, where caching and real devices play a part.
- Which number should I trust for my Shopify store?
- Judge the store by field data: Shopify’s web performance reports, or the field section of PageSpeed Insights and Search Console. Use lab data, such as Lighthouse diagnostics, to find what causes a slow metric.
- How long until a speed fix shows up in the data?
- Field data is a rolling window: 30 days in Shopify’s summary, whose data can also be delayed by up to 36 hours, and 28 days in CrUX. A fix appears gradually as older visits drop out of the window.
- Why doesn’t Lighthouse show INP?
- INP measures responses to real interactions, and a simulated load has no user input. Lighthouse reports Total Blocking Time as a lab proxy for it.