Lighthouse trova le cause. CrUX misura gli utenti. Search guarda il campo, al 75° percentile. Se i due numeri discordano, si crede all'utente.
Un 95 su Lighthouse e un LCP da quattro secondi sul telefono vero non sono un paradosso. Sono due misure diverse. Il laboratorio simula. Il campo registra. Google, per i Core Web Vitals, guarda il campo. Se ottimizzi solo il punteggio in ufficio, stai progettando per te stesso.
In breve: Lighthouse e i test in locale sono utili per trovare cause. I Core Web Vitals che contano per Search arrivano dal Chrome User Experience Report, al 75° percentile, mobile e desktop separati. web.dev lo scrive senza giri: LCP entro 2,5 s, INP entro 200 ms, CLS entro 0,1. Se laboratorio e campo discordano, si crede al campo.
Cosa trovi in questo articolo
Due strumenti, due domande
Lighthouse gira in condizioni controllate: un dispositivo, una rete, una CPU simulati. Risponde a: "in questo setup, cosa è lento e perché?". PageSpeed Insights, nella parte laboratorio, fa lo stesso mestiere. Servono. Danno una lista di cause (immagine senza dimensioni, JS che blocca, font). Non dicono cosa vive l'utente a Catania su 4G, né quello a Milano in wifi da ufficio.
Il campo è il Chrome User Experience Report: visite reali, Chrome, mesi aggregati. Search Console li mostra per URL e per origine. PageSpeed, quando i dati bastano, mette il campo in alto e il laboratorio sotto. La pagina ufficiale sui Web Vitals fissa le soglie sul 75° percentile, non sulla media e non sul best case del tuo Mac.
Il pillar sulla performance come prodotto parte da qui. Questo pezzo è il confronto, in tabella, senza poesia.
Tabella: laboratorio contro campo
| Cosa | Laboratorio (Lighthouse / PSI lab) | Campo (CrUX / Search Console) |
|---|---|---|
| Cosa misura | Una sessione simulata, ora, su un profilo di dispositivo e rete | Visite reali di utenti Chrome, aggregate |
| A cosa serve | Diagnosticare: quale risorsa, quale task, quale elemento LCP | Decidere se il prodotto è usabile per la maggioranza |
| Soglia | Punteggio 0–100 e metriche della run | 75° percentile, mobile e desktop separati |
| Cache | Spesso prima visita, a volte throttling | Misto: chi torna e chi arriva da Google |
| Search | Non è il dato usato per i Core Web Vitals in Search | È il dato usato, insieme ad altri segnali di page experience |
| Limite | Non vede la coda lunga dei telefoni mediocri | Arriva in ritardo, vuole volume, non spiega il "perché" |
La riga che conta: Search non ti chiede il 100 verde. Ti chiede se al 75° percentile LCP, INP e CLS stanno nelle soglie. Il laboratorio ti dice come arrivarci. Confondere le due colonne è il motivo per cui si compra una CDN dopo un 90 in ufficio.
Le soglie non cambiano, cambia chi le misura
| Metrica | Buona | Da migliorare | Scarsa |
|---|---|---|---|
| LCP | ≤ 2,5 s | ≤ 4 s | > 4 s |
| INP | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS | ≤ 0,1 | ≤ 0,25 | > 0,25 |
Fonte: web.dev / Web Vitals e le pagine su LCP, INP, CLS. INP ha sostituito FID come Core Web Vital il 12 marzo 2024. Google Search Central le inquadra nella page experience: un segnale, non l'unico, e non un lasciapassare per la prima pagina.
Stesso numero, due mondi. Un LCP "2,4 s" in Lighthouse su cavo e un LCP "3,8 s" al 75° percentile mobile sono entrambi veri. Il secondo è quello che l'utente paga. Se vendi su scheda prodotto, misura quella URL, non solo la home: lo abbiamo già scritto sull'ecommerce lento.
Quando usare l'uno, quando l'altro
Laboratorio prima quando stai cercando il colpevole: elemento LCP, catena critica, task lunghi, layout shift. DevTools, Lighthouse, un filmato di Performance. Poi si interviene. Senza questa passata, il campo ti dice solo "è rosso".
Campo prima quando devi decidere se il sito è accettabile, se una release ha peggiorato il mobile, se Search Console sta segnalando un gruppo di URL. Non si "passa Lighthouse" per chiudere un ticket di prodotto. Si guarda CrUX sulla URL che porta soldi.
Ha senso tenere entrambi in un report settimanale: una colonna cause, una colonna utenti. Non ha senso innamorarsi del 100 e ignorare un INP da 400 ms sul checkout. La cache HTTP e un database lento si vedono in modo diverso nei due strumenti: il lab può avere cache vuota, il campo no.
Errori da evitare
Dichiarare il sito veloce con un 95 in laboratorio e CrUX rosso sul mobile.
Ottimizzare solo la home perché è quella che Lighthouse apre per default.
Confrontare una run su Mac in ufficio con il 75° percentile di tre mesi di visite.
Aspettare i dati di campo per sistemare un CLS evidente in locale. Il lab basta per quello.
Trattare PageSpeed come un voto scolastico. È un rapporto, con due sezioni. Si leggono tutte e due.
In sintesi
Laboratorio: cause. Campo: utenti. Le soglie LCP, INP, CLS sono le stesse, al 75° percentile. Search guarda il campo. Si misura in lab per capire, in campo per decidere. Se i due numeri non coincidono, il prodotto è quello che vede l'utente, non lo screenshot del 100.
Fonti
web.dev, Web Vitals.
Google Search Central, Core Web Vitals and Google search results.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
