Field data vs lab data: a practical guide for developers

You've been staring at your Lighthouse score for weeks. It's a perfect 100. But your Core Web Vitals assessment in Search Console says you're failing. Welcome to the gap between field data vs lab data: a practical guide for developers—two measurement approaches that look the same but tell completely different stories about your site's real-world performance.

The confusion costs teams thousands of hours. Lab data simulates a single device under controlled conditions. Field data captures what actually happens across millions of real users. Google ranks sites using field data. Your Lighthouse report doesn't.

Two kinds of data: lab and field explained

Lab data and field data measure the same metrics—Largest Contentful Paint, Cumulative Layout Shift, First Input Delay—but under completely different circumstances.

Lab data comes from synthetic testing tools like Lighthouse and WebPageTest. These tools run your site in a controlled environment: a simulated Moto G4 phone on a throttled 4G connection from a fixed geographic location. The same conditions, every time. You get repeatable results that are easy to debug.

Field data comes from real users on real devices with real network conditions. Chrome sends this data to Google's Chrome User Experience Report (CrUX). Your own Real User Monitoring (RUM) setup also captures field data. This is what Google uses for ranking signals and what you see in Search Console's Core Web Vitals assessment.

The differences matter enormously. A visitor on a 5G connection in London sees different performance than someone on 3G in rural India. Lab data won't tell you about either of them.

Optimize for field data: what Google actually uses

Google's Core Web Vitals assessment runs against field data. Specifically, it uses Chrome User Experience Report (CrUX), which aggregates anonymized metrics from millions of Chrome users who've opted into sharing their data.

Your Search Console shows you the percentiles: what percentage of your users experienced good, needs improvement, or poor metrics. If 70% of your sessions hit LCP under 2.5 seconds, you pass that threshold. If 35% hit it, you fail. This distribution comes from real sessions, not from a lab test run against a test device in a controlled environment.

This means a perfect Lighthouse score is meaningless if your field data is poor. You could have a 100 in the lab because your site loads fast on a simulated Moto G4 on 4G. But if your real users include many on slower networks or older devices, your field data will reflect that slower experience.

The implication: optimize against the distribution of your actual users. Know where they are. Know what devices they use. Know their network speeds. Then measure field data to confirm your optimizations work for them.

If you're shipping third-party scripts, they might load instantly in the lab but add 500ms of delay in the field under high network contention. Lab data won't catch this. Field data will.

Use lab for diagnosis: reproduce and confirm

Lab data isn't useless. It's just misused. Lab is the best tool for diagnosis.

When Search Console tells you your LCP is poor, you open Lighthouse to understand why. The lab environment lets you reproduce the issue consistently. You can throttle the network, change the device, load the page 10 times in a row, and see exactly where the bottleneck sits. Was it a slow server response? A render-blocking JavaScript file? An unoptimized image?

The workflow is: diagnose in the lab, then validate in the field.

You suspect a hero image is blocking LCP. Lighthouse running against your site takes 3 seconds to paint the largest element. You investigate the image: it's 2MB, JPEG, not lazy-loaded. You optimize it to 150KB, convert to WebP, and add loading="lazy". Lighthouse now shows LCP at 1.2 seconds. Good.

But you must confirm this in the field. Deploy the change. Wait 28 days for new CrUX data, or check your RUM data within hours. If field data improves, you've won. If it doesn't, something else is degrading real-user experience—maybe a script you didn't see in the lab, or traffic patterns different from your simulation.

Lab excels at repeatable diagnosis. Field confirms real-world impact. Use both.

Collect your own RUM: move beyond CrUX

CrUX data updates monthly and only covers sites with sufficient traffic (typically 28 days of at least thousands of users). Small sites get no CrUX data at all. And you can't slice CrUX by feature, cohort, or user journey—only by page.

Real User Monitoring (RUM) solves this. You instrument your site to send performance metrics from real users directly to your analytics backend. Google's web-vitals library makes this straightforward.

<script>
import {getCLS, getFID, getFCP, getLCP, getTTFB} from 'web-vitals';

// Send metrics to your endpoint
function sendMetric(metric) {
  fetch('/api/metrics', {
    method: 'POST',
    body: JSON.stringify(metric),
    keepalive: true, // crucial for page unload
  });
}

getCLS(sendMetric);
getFID(sendMetric);
getFCP(sendMetric);
getLCP(sendMetric);
getTTFB(sendMetric);
</script>

Now you're collecting real field data continuously. You can segment by device type, network speed, geographic region, or any custom dimension you attach to the metric payload.

Each metric object includes:

• name: the metric identifier (e.g., "LCP")
• value: the measured value in milliseconds
• rating: "good", "needs-improvement", or "poor"
• delta: change from the previous measurement (useful for continuous tracking)
• id: unique session identifier for correlation

You can enrich this data further. Send browser version, connection type (from the navigator.connection API), viewport size, and feature flags. This lets you answer questions lab testing can't: "Do users on 4G see worse LCP than users on 5G?" or "Did enabling that new feature degrade our 75th percentile metric?"

Store this data in your analytics platform or a time-series database. Query it daily. Alert when percentiles degrade. This is your source of truth for real-world performance.

Common mistakes

• Confusing Lighthouse with search ranking: Your Lighthouse score doesn't determine Google ranking. Search Console's Core Web Vitals assessment does, and that uses field data only. Stop chasing a perfect Lighthouse and start chasing good field percentiles.
• Optimizing the lab device instead of your users: If your real traffic is 60% mobile and 40% desktop with an average network speed of 4G, don't spend a week optimizing for 5G. Measure what your users actually experience.
• Assuming field data problems are unfixable: Field variance is higher than lab variance, but it's not random. User cohorts, network conditions, and device types drive most of the variation. Segment your RUM data to find patterns.
• Ignoring the delay between action and measurement: CrUX updates monthly. Your RUM data updates in real time. Use RUM to validate changes quickly, then confirm with CrUX once the data rolls in.
• Setting up RUM poorly and missing crucial context: Sending bare metrics without session IDs, user cohorts, or feature flags makes your RUM data nearly useless. Invest in the instrumentation from day one.

Key takeaways

• Lab data (Lighthouse, WebPageTest) simulates a single device and network condition. Field data (CrUX, RUM) measures real users across real devices and networks. Google ranks using field data.
• Use lab data to diagnose performance problems. Its repeatability makes it ideal for debugging. Deploy your fix, then validate with field data to confirm real-world impact.
• Optimize for the distribution of your actual users, not the simulated Moto G4. Know your traffic composition: geographies, device types, network speeds.
• Collect your own RUM using the web-vitals library. CrUX is useful but limited. RUM lets you segment by cohorts, features, and custom dimensions, giving you actionable insights lab testing can never provide.
• Field data tells you what's broken. Lab data helps you fix it. Use both. Neither alone is enough.