Skip to main content

Field vs Lab Testing: CrUX, Lighthouse & RUM

Field data and lab data tell different stories about your React app's performance. Field data (also called Real-User Monitoring or RUM) comes from actual users visiting your site in production on their own devices and networks. Lab data comes from synthetic tests you run in a controlled environment, like Lighthouse in Chrome DevTools. Google uses field data (the Chrome User Experience Report, or CrUX) to rank pages, making field data the source of truth for SEO and user satisfaction.

What Is Field Data (Real-User Monitoring)?​

Field data is Core Web Vitals metrics collected from real users visiting your site. Every metric is from a different browser, device, network, and geographic location. A user on a Pixel 3 on slow 4G in rural India contributes to field data just as much as a user on a 2024 MacBook on fiber broadband in San Francisco.

Chrome, Edge, and Brave browsers automatically report field data to Google, which publishes it in the Chrome User Experience Report (CrUX). Google uses CrUX data to calculate a site's Core Web Vitals score for ranking (Google Search Central, 2024).

How to Access Field Data​

Chrome User Experience Report (CrUX): Go to https://crux.run and enter your domain. The report shows:

  • Core Web Vitals percentiles (75th, 50th, 25th).
  • Device type breakdown (desktop, tablet, mobile).
  • Network speed distribution (4G, 3G, slow 2G).
  • Geographic distribution.

Google Search Console: Sign in to Search Console, go to Experience → Core Web Vitals. This shows the same CrUX data.

Your own RUM implementation: Install the web-vitals library (article 2) and send metrics to your analytics backend. This gives you first-party field data with custom attributes (page route, user ID, feature flags, etc.).

What Is Lab Data (Lighthouse)?​

Lab data is synthetic performance testing in a controlled environment. Lighthouse simulates a "typical" mobile device (Moto G4) on a slow 4G network, then measures performance metrics. It does not represent a specific real user; it is a simulation designed to catch regressions and provide actionable optimization advice.

Lighthouse is excellent for:

  • Debugging why a metric is high (shows opportunities, diagnostics).
  • Catching regressions during development (before they hit production).
  • Generating optimization recommendations (specific suggestions for your code).
  • Tracking performance over time in CI/CD.

Running Lighthouse​

In Chrome DevTools:

  1. Open DevTools → Lighthouse tab.
  2. Click "Generate report."
  3. Lighthouse measures LCP, INP, CLS, and other metrics.

In CI/CD (using lighthouse CLI):

npm install --save-dev @lhci/cli
lighthouse https://yoursite.com --output-path ./lh-report.html

Field Data vs Lab Data: Key Differences​

AspectField Data (CrUX)Lab Data (Lighthouse)
SourceReal users in productionSynthetic test in lab environment
DevicesDiverse (all devices users use)Simulated Moto G4 (representative)
NetworksReal networks (WiFi, 4G, 3G)Simulated 4G throttling
Page stateUser's actual state (cache, cookies)Fresh page load, cleared cache
Sample sizeMillions of page viewsOne page load
FrequencyAggregated every 28 daysOn-demand, single run
Median or P75P75 (75th percentile)Median (50th percentile)

A site might have a Lighthouse LCP of 1.2 seconds (green, "good") but a CrUX LCP of 3.8 seconds (red, "poor") because Lighthouse tests a top-of-the-line device on good simulated 4G, while real users include slow phones on 3G networks and in areas with poor connectivity.

Understanding Percentiles in Field Data​

CrUX reports the 75th percentile (P75) of Core Web Vitals, not the median. This means:

  • 75% of real users experience better performance than the reported value.
  • 25% of real users experience worse performance.

A site with CrUX LCP of 2.5 seconds (the "good" threshold) means:

  • 75% of users see LCP ≤ 2.5s (good experience).
  • 25% of users see LCP > 2.5s (slower experience, often mobile or slow networks).

Google uses P75 because it penalizes sites that ignore slow-network and slow-device users.

Why Field Data Matters for SEO​

Google announced in May 2021 that Core Web Vitals (LCP, INP, CLS) are ranking factors, evaluated using CrUX field data. A page that passes all three Core Web Vitals gets a ranking boost; a page that fails even one gets a ranking penalty. Google Search results also show a "Core Web Vitals" badge for qualifying pages (visible to searchers as a trust signal).

Field data is more representative of SEO reality because:

  1. Real-world networks: CrUX includes slow 3G, rural networks, and cellular congestion that lab tests miss.
  2. Real-world devices: Real users have older, slower phones; lab simulations are faster than average.
  3. Real-world user behavior: Users may have browser extensions, ad blockers, or other customizations that change performance.

Optimizing for lab data alone will not improve field data. You must optimize your code so that it performs well even on slow networks and slow devices.

Reconciling Field and Lab Data​

If your Lighthouse score is good but CrUX is poor:

  1. Check CrUX percentiles: Click on https://crux.run. If P75 LCP is 2.8s and median is 1.5s, your slowest 25% of users are the problem. They are on slow networks or devices.
  2. Simulate slow networks in DevTools: In Chrome DevTools → Network tab, throttle to "Slow 4G" and rerun Lighthouse. Scores should worsen, matching CrUX more closely.
  3. Test on low-end phones: Borrow a Pixel 3 or older Android phone and test. Slow CPUs exacerbate INP problems.
  4. Implement RUM field data: Send custom RUM data with network speed and device type:
// src/utils/analytics.js
import { getLCP, getINP, getCLS } from 'web-vitals';

function getRUMAttributes() {
  const ua = navigator.userAgent;
  const conn = navigator.connection || { effectiveType: 'unknown' };
  
  return {
    effectiveType: conn.effectiveType, // 4g, 3g, 2g, slow-2g
    deviceType: /mobile/i.test(ua) ? 'mobile' : 'desktop',
    deviceMemory: navigator.deviceMemory || 'unknown',
  };
}

getLCP(metric => {
  const attrs = getRUMAttributes();
  fetch('/api/analytics/lcp', {
    method: 'POST',
    body: JSON.stringify({
      ...metric,
      ...attrs,
    }),
    keepalive: true,
  });
});

This RUM data reveals which network/device combinations are slowest.

Setting Baselines and Alerts​

Monitor field data trends:

  1. Check CrUX weekly: Go to https://crux.run weekly and record P75 scores. If LCP rises from 2.0s to 2.5s, a regression occurred.
  2. Compare CrUX P75 vs your RUM P75: If they match, your RUM implementation is accurate.
  3. Set alerts: If P75 LCP rises above 2.5s or P75 INP rises above 200ms, notify your team.

Example Datadog RUM alert (pseudo-code):

// Pseudo-code for monitoring backend
const cruxLcp = getCrUXData('your-site.com').lcp.percentile75;

if (cruxLcp > 2.5) {
  alert('REGRESSION: LCP above threshold');
}

Key Takeaways​

  • Field data (CrUX, RUM) comes from real users and is used by Google for ranking.
  • Lab data (Lighthouse) is synthetic and useful for debugging and catching regressions.
  • CrUX reports the 75th percentile (P75), so 25% of users experience worse performance.
  • A good Lighthouse score does not guarantee good field data; real users have slow networks and devices.
  • Use field data as your source of truth; use lab data as a debugging tool.
  • Implement RUM with custom attributes (network, device, page route) to identify which segments are slowest.

Frequently Asked Questions​

Why does Google use P75 instead of median (P50) for Core Web Vitals?​

P75 focuses on the experience of the slower 25% of users, ensuring sites don't optimize only for fast users. A site that provides a great experience for fast users but poor experience for slow-network users will fail Core Web Vitals. P75 penalizes such sites.

How do I check if CrUX data is available for my site?​

Go to https://crux.run or Google Search Console. If no data appears, your site may not have enough traffic or real user sessions. CrUX requires at least 28 days of user data and a minimum user volume (varies by Google, but typically 1,000+ users in a 28-day period).

Can I use Lighthouse to optimize for CrUX?​

Partially. Lighthouse identifies bottlenecks and suggests optimizations, but Lighthouse scores on a single (simulated) device. To truly optimize for CrUX (P75 across diverse devices), you must test on real devices and slow networks, and implement RUM to measure real-user performance.

Should I ignore Lighthouse if it conflicts with CrUX?​

No. Lighthouse is a leading indicator—if Lighthouse scores drop, CrUX often follows weeks later. Use Lighthouse to catch regressions early in development, then verify the fix with field data.

Further Reading​