Performance
Misurare l'LCP: laboratorio contro campo
Il LCP di campo dice se la pagina passa, quello di laboratorio dice perché. Qui il campo segna 1.724 ms di p75 e due run di lab differiscono del 42%.
In sintesi
- Il campo decide se la pagina passa, il laboratorio spiega quale parte la rallenta.
- 229 letture di campo hanno dato un p75 di 1.724 ms, con 33 sopra i 2,5 s.
- Due run di Lighthouse a cinque minuti di distanza hanno misurato 3,5 s e 5,0 s.
Il LCP di campo dice se la pagina passa per gli utenti reali; il LCP di laboratorio dice perché, ma due run di fila possono differire del 42%. Qui il campo segna 1.724 ms di p75, il laboratorio 3,5 s e 5,0 s sulla stessa URL.
Stessa metrica, due domande
| Dimensione | Campo | Laboratorio |
|---|---|---|
| Fonte | beacon RUM, 229 letture | Lighthouse 13.6.0, una run |
| Finestra | 25 ottobre - 1 novembre 2026 | 28 ottobre 2026 |
| Risponde a | la pagina passa? | perché non passa? |
| p75 LCP | 1.724 ms | 3,5 s e 5,0 s in due run |
I due comandi
curl -sS "https://ui.eneawork.it/api/rum/summary?days=7" -H "x-admin-token: $ADMIN_TOKEN"
npx lighthouse https://ui.eneawork.it --only-categories=performance --output=json --output-path=./lcp.jsonIl primo comando restituisce il p75 per metrica e per device sulle ultime visite; il secondo produce un report con LCP, CLS e TBT di una singola esecuzione. Servono entrambi: uno dice se il problema esiste, l'altro dove nasce.
Perché due run non coincidono
Lighthouse simula una CPU più lenta e una rete diversa a ogni esecuzione, e la cache parte vuota solo se la azzeri. Script di terze parti, font e immagini hero arrivano con tempi diversi: da qui i 1.475 ms di scarto tra due run a cinque minuti di distanza.
Come leggere il divario
- Lab: Lighthouse o WebPageTest con rete e CPU simulate. Ripetibile, serve a confrontare due build.
- Field: CrUX o RUM sui visitatori reali. Riflette dispositivi e reti vere, arriva con circa 28 giorni di ritardo.
- Se i due divergono non sono in contraddizione: il lab misura la build, il field misura gli utenti.
La limitazione
229 letture non sono un campione: il p75 non è segmentato per connessione e 10 letture su una route si spostano con una sola visita lenta. Il beacon conta solo le visite che eseguono JavaScript, quindi chi blocca gli script non entra nel dato.
Dove continuare
Nel catalogo EneUI: 111.985 componenti, 1.556 blocchi e il record image auto slider, un carosello che può diventare l'elemento LCP. Le guide: cosa peggiora l'LCP e cosa sono i Core Web Vitals; le soglie in Lighthouse CI spiegano come fissare il budget in una pipeline.
Domande frequenti
Quale dato devo guardare per primo?
Il campo, perché è quello che Google usa per la soglia. Se il p75 di campo è sotto i 2,5 s la pagina passa, qualunque cosa dica una singola run di laboratorio.
Perché il laboratorio misura un LCP più alto del campo?
Perché Lighthouse simula una CPU lenta e una rete mobile anche quando gli utenti reali navigano in fibra. Il laboratorio risponde a una domanda diversa: quanto costa la pagina in condizioni dichiarate.
Quante letture servono per un p75 affidabile?
Non c'è un numero fisso, ma sotto le cento letture il p75 si muove con poche visite. Qui 10 letture su una route bastano a produrre un valore che cambia ogni giorno.
Il beacon RUM sostituisce il Chrome UX Report?
No. Il CrUX aggrega tutti gli utenti Chrome che hanno attivato la telemetria; il beacon vede solo chi visita il sito con JavaScript attivo. I due numeri possono divergere.
Come fisso una soglia in CI?
Usa Lighthouse CI con un budget sull'LCP simulato e confronta la mediana di tre run, non una sola. Il campo resta il giudice finale.