Lab data and field data
Fast for us, slow for them
Shard Garden's web build scores 98 in Lighthouse on Kai's laptop. The same week, Search Console says the game's page is slow on phones. Both are true.
Lab data is one test run in fixed conditions. Field data is what real players actually got. Course 1 said the field wins when they disagree. Now we find out where field data comes from, why it disagrees, and how to collect our own.
Where Google's field data comes from
PageSpeed Insights and Search Console read the Chrome User Experience Report (CrUX): numbers from real Chrome users over the last 28 days.
- Only users who turned on usage statistics reporting and sync their browsing history count.
- Only Chrome on computers and Android. Chrome on iPhones, Android WebView and other browsers built on Chromium, like Edge, are left out.
- A page must be public (no
noindex) and have enough visitors. Google doesn't say how many.
Quick check
Which Shard Garden players can never show up in CrUX?
- Players using Chrome on an iPhone
- Players using Chrome on Android who share usage statistics and sync
- Players using Chrome on a Windows laptop who share usage statistics and sync
Show the answer
Players using Chrome on an iPhone
CrUX lists Chrome on iOS as an exception, so those players are missing from Google's field data. The other two meet every rule.
One number for thousands of visits
Field tools report the 75th percentile: line up every visit from fastest to slowest, and take the one three quarters of the way along. Three in four visits were at least that fast.
web.dev shows an example page. 88% of visits had a good LCP (the biggest thing on screen appearing), 8% needed improvement and 4% were poor. The field's 75th percentile was 1.8 seconds. The lab test of the same page said 3.0 seconds. The lab was slower than real players.
Why lab and field disagree
- One device or thousandsA lab test uses one device, one network and one place. Players bring every phone and every signal.
- Empty cache or full cacheLab tests usually start with nothing saved. Returning players often have our files cached already.
- A different biggest thingThe largest element can change with screen size, language or an A/B test.
- Loading or the whole visitLab CLS (layout shift) only counts what moves during load. The field counts the whole visit.
Quick check
Lighthouse can measure Shard Garden's INP (how fast taps get answered) in the lab.
- True
- False
Show the answer
False
Nobody taps during a Lighthouse run, so there is nothing to measure. Lighthouse reports Total Blocking Time (TBT) instead, a lab clue for INP problems.
Our own field data: RUM
Real User Monitoring (RUM) means the page measures itself on each player's device and sends the numbers home. It covers browsers CrUX leaves out, and we can split results by device, country or game screen.
The Chrome team's web-vitals library is about 3 KB after Brotli compression. Remy adds three lines: onLCP(send), onINP(send) and onCLS(send). Each reports its number to our send function, which posts it to our analytics server with navigator.sendBeacon.
Read the numbers
1Laptops 90 ms2Android, high-end 140 ms3Android, budget 380 ms4iPhone 160 ms
Good INP is 200 ms or less, and poor is over 500 ms. Where should Remy look first?
- Budget Android phones
- Laptops
- iPhones
Show the answer
Budget Android phones
Budget Android phones are the only group above 200 ms, so they need improvement. Every other group is already good, and fixing laptops would help the players who need it least.
Field first, lab to fix
The studio's routine: field data says what is slow and for whom. The lab, the same test every time, helps find why and proves a fix worked. Then the field confirms it over the next 28 days.
Bolt says: Next: LCP, the first of the three numbers, and the four parts hidden inside it.
Fact-checked 11 October 2026
- web.dev: Why lab and field data can be different web.dev
- Chrome for Developers: CrUX methodology developer.chrome.com
- web.dev: Web Vitals web.dev
- GoogleChrome: web-vitals library github.com