Perché la velocità del tuo sito non corrisponde a Lighthouse

You run Lighthouse in Chrome DevTools. Score: 97. Green across the board. You celebrate, deploy, and check Search Console a month later. Core Web Vitals: Needs Improvement. LCP is 3.2 seconds. How?

This isn't a bug. It's a fundamental gap between lab data (what Lighthouse measures) and field data (what real users experience). Understanding this gap is essential for anyone who takes web performance seriously. Otherwise, you'll optimize for the wrong things and wonder why Google's rankings don't reflect your "perfect" score.

Lab Data vs Field Data: The Fundamental Difference

Lab data is collected in a controlled environment. Same device simulation, same network throttling, same conditions every time. Lighthouse, WebPageTest, and Chrome DevTools performance audits produce lab data.

Field data is collected from real users on real devices over real networks. Chrome User Experience Report (CrUX), web-vitals.js, and commercial RUM (Real User Monitoring) tools produce field data.

Characteristic	Lab Data (Lighthouse)	Field Data (CrUX/RUM)
Device	Simulated Moto G Power	Actual user devices (thousands of models)
Network	Simulated 4G (1.6Mbps)	Actual connections (2G through fiber)
Location	Your machine	Global user locations
Sample size	1 page load	Thousands of page loads over 28 days
Interactions	None (page load only)	Real clicks, scrolls, taps
Third-party scripts	May be blocked/delayed	Fully loaded in real conditions
Caching	Cold cache (first visit)	Mix of cold and warm cache
INP measurement	Not possible	Full interaction tracking

The most critical difference: Lighthouse cannot measure INP (Interaction to Next Paint). INP requires actual user interactions — clicks, taps, key presses. Lighthouse can only simulate page load, not user behavior. So your Lighthouse score might be 100 while your real INP fails badly.

Why Lighthouse Scores Mislead

The Throttling Problem

Lighthouse simulates a mid-tier mobile device with a 4G connection. The throttling is applied via software, not hardware. This means:

• CPU throttling is approximate. A 4x CPU slowdown on your M3 MacBook Pro doesn't accurately represent a $150 Android phone with 3GB RAM.
• Network throttling doesn't capture real-world packet loss, DNS failures, or CDN edge cache misses.
• The simulated device has more memory and a faster CPU than most real-world mobile devices.

Result: Lighthouse consistently underestimates real-world performance problems on low-end devices. A site that scores 90 on Lighthouse can score 45 on a real budget phone.

Single-Page, Single-Visit Bias

Lighthouse measures one page load from cold cache. Real users:

• Navigate multiple pages in a session (warm cache changes performance dramatically)
• Interact with the page (triggering JavaScript, layout recalculations, network requests)
• Have browser extensions that inject scripts and modify page behavior
• May have multiple tabs open, competing for memory and CPU

Third-Party Script Timing

Third-party scripts (analytics, chat widgets, ads, consent managers) behave differently in lab and field conditions:

• Lab: Scripts may load from cache, servers may respond faster to known test IPs, consent managers may not trigger
• Field: Scripts load from origin, servers may throttle based on region, consent managers add 200-500ms of blocking time

We've seen sites where Lighthouse reports 1.2s LCP but field data shows 2.8s LCP — the entire 1.6s difference caused by a consent manager and chat widget that didn't fully load during the Lighthouse test.

Score Variability

Run Lighthouse 10 times on the same page. You'll get 10 different scores. Variance of 5-10 points is normal. This means the difference between a 92 and an 87 is noise, not a real performance regression.

Lab data is useful for relative comparisons (before vs after a specific change) but not for absolute performance assessment.

Setting Up Real User Monitoring

web-vitals.js (Free, Essential)

Google's open-source library for collecting Core Web Vitals from real users:

import { onLCP, onCLS, onINP } from 'web-vitals';

function sendMetric({ name, value, rating, id }) {
  const body = JSON.stringify({
    metric: name,
    value: Math.round(value),
    rating, // "good", "needs-improvement", or "poor"
    page: window.location.pathname,
    deviceType: /Mobi/.test(navigator.userAgent) ? 'mobile' : 'desktop',
  });

  // Use sendBeacon for reliability (fires even on page unload)
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', body);
  } else {
    fetch('/api/vitals', { method: 'POST', body, keepalive: true });
  }
}

onLCP(sendMetric);
onCLS(sendMetric);
onINP(sendMetric);

Store the data in your analytics database and build dashboards that show:

• P75 values per metric (what Google uses for ranking)
• Breakdown by device type (mobile vs desktop)
• Breakdown by page template (blog vs landing page vs product)
• Trend over time (weekly aggregation)

CrUX API and Dashboard

The Chrome User Experience Report provides free field data from Chrome users who opt into sharing usage statistics. Access it through:

• CrUX API: Programmatic access to origin-level and URL-level data
• CrUX Dashboard (Looker Studio): Visual dashboard with historical trends
• PageSpeed Insights: Shows CrUX data alongside Lighthouse scores

CrUX data has a 28-day rolling window. It's the exact data Google uses for Core Web Vitals ranking evaluation. If your CrUX data says your LCP is 3.2s, that's what Google sees — regardless of what Lighthouse says.

Limitation: CrUX only reports data for URLs and origins with sufficient traffic. Low-traffic pages may not have CrUX data at all. That's where your own web-vitals.js implementation fills the gap.

Commercial RUM Platforms

For deeper analysis, commercial RUM platforms offer session replay, detailed breakdowns, and alerting:

Platform	Starting Price	Strengths
SpeedCurve	$12/month	Developer-focused, excellent visualizations
Sentry Performance	Free tier	Error tracking + performance in one
Datadog RUM	$15/month	Full-stack observability integration
New Relic Browser	Free tier	Enterprise APM integration

For most sites, web-vitals.js + CrUX provides sufficient monitoring. Commercial RUM is worth the investment when you need session-level debugging or performance alerting integrated into your operations workflow.

Reconciling Lab and Field Data

Don't choose one over the other. Use both, for different purposes:

Lab Data (Lighthouse) Is For:

• Debugging specific issues. Lighthouse's filmstrip, performance trace, and diagnostics panel pinpoint exactly what's causing a performance problem.
• Regression testing in CI. Run Lighthouse CI on every deploy to catch performance regressions before they reach users.
• Comparing implementations. A/B testing two approaches on the same test infrastructure eliminates device and network variables.
• Identifying optimization opportunities. Lighthouse's recommendations (unused JavaScript, render-blocking resources, image optimization) are actionable debugging output.

Field Data (RUM/CrUX) Is For:

• Measuring what Google actually uses. CrUX field data is the ranking signal. Period.
• Tracking real user experience. Your p75 user on mobile in India has a very different experience than your Lighthouse test on a MacBook in your office.
• Detecting third-party script impact. Field data captures the full weight of every script that runs on your pages in production.
• Measuring INP. Only field data can measure interaction responsiveness.

The Decision Framework

Question	Use
"Is our site fast for real users?"	Field data (CrUX, RUM)
"Why is LCP slow?"	Lab data (Lighthouse trace)
"Did our latest deploy hurt performance?"	Lab data (Lighthouse CI)
"Are we passing Core Web Vitals for Google?"	Field data (CrUX)
"Which third-party scripts hurt us most?"	Field data (RUM with attribution)
"What's our INP score?"	Field data (web-vitals.js)

Practical Workflow

At Empirium, our performance workflow combines both:

1. Continuous: web-vitals.js collects field data from every page view
2. On deploy: Lighthouse CI runs against staging, blocking deploys that regress
3. Weekly: Review CrUX dashboard for trend changes
4. Monthly: Full Lighthouse audit of all page templates with detailed analysis
5. On alert: When field data shows degradation, use Lighthouse trace to diagnose

This dual approach catches issues before deployment (lab) and verifies real-world performance after deployment (field). Read our complete optimization guide in Core Web Vitals: The Complete 2026 Guide.

FAQ

Can I use Lighthouse CI to enforce performance budgets?

Yes, and you should. Lighthouse CI runs automated Lighthouse tests in your CI pipeline and can assert specific thresholds. Set budgets for LCP, CLS, Total Blocking Time (a lab proxy for INP), and bundle sizes. Fail builds that exceed budgets. This catches regressions before they reach production. But remember — passing Lighthouse CI doesn't guarantee good field performance.

How do I handle Lighthouse score variability?

Run multiple tests (3-5) and use the median. In Lighthouse CI, configure numberOfRuns: 5 and use the median result for assertions. For manual testing, run at least 3 times and use the middle value. Ignore single-run outliers — they're noise.

Do third-party scripts affect Lighthouse differently than real users?

Yes. Third-party scripts can be partially blocked or load faster during Lighthouse tests because the test runs in a controlled environment. In field conditions, ad networks, consent managers, and chat widgets often add 500ms-2s of loading time that Lighthouse doesn't capture. Always validate third-party script impact with field data, not lab data.

What's a good p75 target for Core Web Vitals?

For competitive SEO, target p75 values well below Google's "good" thresholds: LCP under 1.5s (not 2.5s), CLS under 0.05 (not 0.1), INP under 150ms (not 200ms). The "good" threshold is the minimum for passing — not the target for competitive advantage. Sites at the top of the "good" range are barely passing; sites well within "good" have a genuine ranking advantage.

Should I optimize for Lighthouse score or field data?

Field data. Always. Lighthouse scores are useful for debugging and regression testing, but Google ranks based on field data (CrUX). If your Lighthouse score is 60 but your CrUX data passes all Core Web Vitals, you're fine. If your Lighthouse score is 100 but your CrUX data fails, you have a ranking problem. Optimize for what your real users experience.