Diagnostica il LCP con il pannello Performance di Chrome DevTools

Questa guida fa parte dell'hub sul Largest Contentful Paint (LCP). Copre un solo strumento: il pannello Performance dei Chrome DevTools. Registrerai una traccia con throttling, leggerai le quattro sotto-parti del LCP e saprai esattamente quale correggere per prima.

I DevTools vengono per ultimi, non per primi

Il pannello Performance è uno strumento da laboratorio. Misura il caricamento di una pagina, su un dispositivo, su una rete: la tua. Questo lo rende il posto sbagliato per iniziare e il posto giusto per finire.

Inizia con i field data. CrUX ti dice se il LCP è davvero un problema. I dati RUM ti dicono quali pagine e quali elementi sono lenti per i tuoi utenti reali. Quel flusso di lavoro è spiegato passo passo in Correggi e identifica i problemi del LCP. I DevTools rispondono poi all'unica domanda rimasta: perché.

Se salti i field data, finisci per ottimizzare la pagina che ti capita di testare sulla connessione che ti ritrovi. Questo è lo schema che vedo in quasi ogni audit: la macchina del programmatore passa il test, il p75 di CrUX fallisce e sono tutti confusi. Hai misurato un laptop veloce su fibra. I tuoi utenti sono su un Android di fascia media in treno.

La vista live delle metriche

Apri i DevTools (Ctrl+Shift+I su Windows e Linux, Cmd+Option+I su Mac) e vai alla scheda Performance. Il pannello non si apre più vuoto. Prima di registrare qualsiasi cosa, mostra una vista live delle metriche con il LCP, il CLS e l'INP della pagina in cui ti trovi, misurati localmente mentre navighi.

Tre cose in questa vista sono utili per lavorare sul LCP. Prima di tutto, nomina l'elemento del LCP e passandoci sopra con il mouse lo evidenzia sulla pagina. Quindi non devi indovinare quale immagine o intestazione ha scelto il browser. Inoltre puoi abilitare i field data in questa vista. I DevTools estraggono quindi i numeri CrUX per l'URL e l'origin e li mostrano accanto ai tuoi valori locali. Se il tuo LCP locale segna 0,8 secondi e il p75 dei field data segna 3,1 secondi, questo divario è la tua prima scoperta: la tua macchina non è rappresentativa e il throttling non è opzionale.

Un consiglio rapido: se vuoi che l'elemento del LCP venga evidenziato su qualsiasi pagina senza aprire i DevTools, usa la nostra estensione Chrome gratuita Core Web Vitals Visualizer.

Imposta il throttling prima di registrare

Una traccia senza throttling sulla macchina di un programmatore è quasi inutile. I numeri saranno ottimi e nessuno di essi corrisponderà a ciò che vivono i tuoi utenti. Imposta il throttling sia per la CPU che per la rete nel pannello prima di registrare.

• Throttling della CPU: usa il rallentamento 4x come impostazione predefinita per i test mobile. Il 20x approssima un dispositivo di fascia bassa. Le versioni recenti di Chrome possono anche calibrare i preset per la tua macchina specifica: l'opzione Calibrate genera preset mobile di fascia bassa e media basati sulla velocità del tuo hardware. Questo è importante perché 4x su un desktop veloce equivale a un dispositivo molto diverso rispetto a 4x su un vecchio laptop.
• Throttling della rete: usa Slow 4G. Questo è il preset che si chiamava Fast 3G prima che Chrome lo rinominasse, ed è ciò che Lighthouse simula per il mobile. Fast 4G è l'opzione più leggera per testare connessioni migliori.

Quando i field data sono abilitati, i DevTools possono persino consigliare un preset di throttling che corrisponde all'esperienza dei tuoi utenti reali. Usalo. Per il ragionamento completo dietro a queste impostazioni, vedi la nostra guida sulle migliori impostazioni di rete dei DevTools per i Core Web Vitals.

Registra il caricamento di una pagina

Fai clic sul pulsante "Record and reload". Chrome naviga verso una pagina vuota, avvia la traccia, carica la tua pagina e interrompe la registrazione da solo un paio di secondi dopo la fine del caricamento. Per il LCP non devi toccare nulla durante la registrazione. Tieni le mani lontane dalla pagina.

Un consiglio rapido: registra in una finestra in incognito con le estensioni disabilitate. Le estensioni iniettano script in ogni pagina e quegli script compaiono nella tua traccia come long task che non hanno nulla a che fare con il tuo sito.

Leggi l'insight LCP breakdown

Dopo il completamento della traccia, la barra laterale Insights a sinistra elenca ciò che i DevTools hanno trovato. Quello che ti serve è LCP breakdown (le versioni precedenti di Chrome lo chiamano LCP by phase). Divide il tempo del LCP nelle sue quattro sotto-parti:

Per un LCP di testo senza un webfont non c'è nulla da scaricare, quindi le due sotto-parti della risorsa sono zero e tutta la storia è TTFB più ritardo di rendering.

Passa il mouse su una sotto-parte nell'insight e i DevTools evidenziano quella finestra esatta nella timeline. Fai clic su di essa e la timeline fa uno zoom, così puoi vedere quali richieste e task rientrano in quella finestra. E se hai abilitato i field data, l'insight mostra il valore p75 di CrUX accanto a ciascuna sotto-parte da laboratorio (quando CrUX ha dati sul LCP delle immagini per il tuo sito). Questo confronto è la funzione più sottovalutata nel pannello. Ti dice se la traccia che stai fissando assomiglia a ciò che vivono realmente i tuoi utenti, prima di passare un pomeriggio a correggerla.

Come dovrebbe apparire un breakdown sano? Le linee guida di Google indicano che le due sotto-parti di ritardo dovrebbero essere vicine allo zero (sotto il 10% del LCP ciascuna), con quasi tutto il tempo dedicato al TTFB e al download vero e proprio. La nostra ricerca sui Core Web Vitals su milioni di caricamenti di pagina mostra quanto la realtà sia lontana da questo: il TTFB prende il 48%, il ritardo di caricamento il 24%, la durata del caricamento solo il 10% e il ritardo di rendering il 17%. Rileggilo: sul sito mediano, le due fasi di attesa insieme sprecano quattro volte più tempo del download stesso. Nulla viene scaricato durante quelle fasi. E nulla viene renderizzato. Il browser sta aspettando un lavoro che avrebbe potuto iniziare prima, ed è per questo che queste due sotto-parti sono il primo posto in cui cercare miglioramenti.

L'insight LCP request discovery

Quando il LCP è un'immagine, c'è un secondo insight che vale la pena aprire: LCP request discovery. Esegue tre controlli sulla richiesta del LCP:

• È applicato fetchpriority="high" all'immagine (o al suo preload)?
• La richiesta è individuabile nel documento HTML iniziale?
• Il lazy loading è correttamente non applicato ad essa?

Ogni controllo fallito indica un problema di scoperta. L'insight annota anche la timeline con il momento in cui l'immagine avrebbe potuto iniziare il download e una stima del tempo che stai perdendo. Ciascuno di questi tre fallimenti ha una correzione concreta e tutti sono trattati nella guida al ritardo di caricamento della risorsa.

Leggi la timeline da solo

Gli insight coprono i casi comuni. Per tutto il resto leggi direttamente la traccia. Tre tracce sono importanti per il LCP.

La traccia Timings mostra i marker per l'FCP, il LCP, il DCL e l'evento di load. Il marker del LCP è il momento in cui l'elemento è stato renderizzato. Tutto ciò che stai diagnosticando accade alla sua sinistra.

La traccia Network mostra ogni richiesta. Trova la risorsa del LCP e guarda quando inizia, non solo quanto tempo impiega. Una richiesta che inizia a 2,5 secondi in un LCP di 3 secondi è un problema di scoperta e nessuna quantità di compressione dell'immagine la salverà. Se avessi reso quell'immagine individuabile fin dai primi byte HTML, il download sarebbe iniziato mentre il browser stava ancora analizzando l'head.

La traccia Main mostra il lavoro del main thread. I long task sono segnalati con un triangolo rosso nell'angolo. Lo schema da cercare: la risorsa del LCP ha finito il download, ma il marker del LCP si trova a centinaia di millisecondi più a destra. Quel divario è il ritardo di rendering dell'elemento e di solito uno di quei task segnalati ne è il responsabile. Passa il mouse sul task per vedere quale script ne è la causa. Nella mia esperienza è un tag manager o uno script di consenso molto più spesso del tuo stesso codice.

Correggi ciò che hai trovato

La sotto-parte più grande nel breakdown decide dove andrai dopo: TTFB, ritardo di caricamento della risorsa, durata del caricamento della risorsa o ritardo di rendering dell'elemento. Se l'elemento del LCP è un'immagine, la guida Ottimizza l'immagine LCP le attraversa tutte e quattro.

Una nota conclusiva: una pagina pre-renderizzata mostra tutte e quattro le sotto-parti quasi a zero, perché il browser ha fatto tutto il lavoro prima che l'utente cliccasse. Se il tuo problema di LCP riguarda le navigazioni all'interno del tuo sito piuttosto che le landing page, le speculation rules possono farti saltare l'intera diagnosi.