Può essere complicato migliorare la Largest Contentful Paint (LCP) di una pagina, spesso con più parti mobili e compromessi. Questo post esamina i dati reali provenienti da caricamenti di pagine reali sul web per determinare dove gli sviluppatori dovrebbero concentrare i propri sforzi di ottimizzazione.
Consiglio della versione classica di LCP: riduci le dimensioni delle immagini.
Per la maggior parte delle pagine sul web, l'elemento LCP è un'immagine. Quindi è naturale supporre che il modo migliore per migliorare LCP sia ottimizzare l'immagine stessa.
A circa cinque anni dall'introduzione di LCP, questo è stato spesso il consiglio principale. Assicurati che le immagini siano di dimensioni adeguate e compresse sufficientemente. In questo caso, utilizza un formato immagine del XXI secolo. Lighthouse ha anche tre diversi controlli per fornire questi suggerimenti.
Il motivo per cui si tratta di un consiglio così comune è che è facile misurare un numero eccessivo di byte e che è facile suggerire strumenti di compressione delle immagini. A seconda delle pipeline di build e deployment, potrebbe anche essere facile da implementare.
Se sì, fallo! Inviare meno byte agli utenti è quasi sempre un vantaggio. Esistono molti siti sul web che continuano a pubblicare immagini inutilmente grandi, che anche la compressione di base potrebbe risolvere.
Tuttavia, quando abbiamo iniziato ad analizzare i dati sulle prestazioni sul campo per gli utenti di Chrome per capire dove viene solitamente speso il tempo per LCP, abbiamo scoperto che il tempo di download delle immagini non è quasi mai un collo di bottiglia.
Al contrario, altre parti dell'LCP rappresentano un problema molto più grande.
Analisi della sottoparte LCP
Per capire quali sono le principali aree di opportunità per migliorare la metrica LCP, abbiamo esaminato i dati delle sottoparti della metrica LCP, come descritto in Ottimizzare l'LCP.
Sebbene per ogni pagina e framework venga impiegato un approccio diverso al caricamento e alla visualizzazione di quello che diventa l'elemento LCP della pagina, ognuna può essere suddivisa in queste sottoparti:
Come citazione dell'articolo, le sottoparti sono:
- Tempo per primo byte (TTFB)
- Il tempo che intercorre tra l'avvio del caricamento della pagina da parte dell'utente e il momento in cui viene avviato il browser riceve il primo byte della risposta al documento HTML.
- Ritardo del caricamento delle risorse
- Il tempo che intercorre tra la TTFB e l'avvio del caricamento della risorsa LCP da parte del browser. Se
L'elemento LCP non richiede un carico di risorse per il rendering, questa volta è
0. - Durata del caricamento delle risorse
- Il tempo necessario per caricare la risorsa LCP stessa. Se l'LCP
non richiede un carico di risorse per il rendering, questa volta è di
0. - Ritardo di rendering dell'elemento
- Tempo che intercorre tra il termine del caricamento della risorsa LCP e il momento in cui termina il caricamento dell'elemento LCP eseguire il rendering completo.
Dati reali sul rendimento della navigazione
| Classificazione LCP | TTFB (ms) | Ritardo nel caricamento delle immagini (ms) | Durata del caricamento delle immagini (ms) | Ritardo di rendering (ms) |
|---|---|---|---|---|
| Buono | 600 | 350 | 160 | 230 |
| Richiedono miglioramenti | 1.360 | 720 | 270 | 310 |
| Scadente | 2.270 | 1.290 | 350 | 360 |
Per questo post, abbiamo utilizzato i dati delle navigazioni nelle pagine con un'immagine LCP di sottorisorsa in Chrome per dare un'occhiata alle sottoparti dell'LCP. Abbiamo già esaminato questo tipo di dati, ma mai dai dati sul campo per capire dove gli utenti reali trascorrono il loro tempo mentre aspettano l'LCP di una pagina.
Come per i Core Web Vitals, abbiamo preso il 75° percentile (p75) di ogni sottoparte LCP per ogni origine nel set di dati CrUX, ottenendo quattro distribuzioni di valori p75 (una per ogni sottoparte). Per riassumere queste distribuzioni, abbiamo preso la mediana di questi valori in tutte le origini per ciascuna delle quattro sottoparti dell'LCP.
Infine, abbiamo suddiviso le origini in bucket a seconda che abbiano un valore "buono", "richiede miglioramenti" o "scarso" LCP al 75° percentile. Ciò consente di mostrare ciò che distingue un'origine con un valore LCP buono da un'origine con un valore LCP basso.
Vuoi ridurre le dimensioni dell'immagine LCP? Questa volta con i dati
La durata di caricamento è la misura del tempo necessario per recuperare la risorsa LCP, in questo caso un'immagine. Questo tempo è solitamente proporzionale al numero di byte nell'immagine, quindi è consigliabile ridurre questo numero di byte.
Se si analizza il tempo trascorso nei grafici precedenti, una cosa interessante è che non c'è molto tempo dedicato alla durata del caricamento delle immagini. Infatti, si tratta della sottoparte LCP più breve in tutti i bucket LCP. La durata del caricamento è maggiore per le origini LCP con scarso rendimento rispetto alle origini LCP buone, ma questo non è un caso in cui il tempo viene in gran parte dedicato.
La maggior parte delle origini con un LCP basso trascorre meno del 10% del tempo LCP p75 a scaricare l'immagine LCP.
Sì, devi assicurarti che le immagini siano ottimizzate, ma questo è solo uno degli aspetti del miglioramento della metrica LCP. E da questi dati è chiaro che, per la tipica origine sul web, i potenziali guadagni in millisecondi per LCP nel complesso sono ridotti, a prescindere da quanto sia sofisticato lo schema di compressione.
Un'ultima sorpresa: una volta i dispositivi mobili e la qualità delle reti mobili erano in genere la causa della lentezza dei caricamenti. Una volta ci aspettavamo che un normale telefono impiegasse più volte più tempo a scaricare la stessa immagine di un computer su una connessione cablata. I dati suggeriscono che non è più così. Per origini con LCP basso, la durata mediana del caricamento delle immagini p75 è più lenta di solo il 20% sui dispositivi mobili rispetto a quelle sui computer.
Tempo per primo byte (TTFB)
Per le navigazioni che effettuano una richiesta di rete, TTFB richiederà sempre del tempo. Per eseguire una ricerca DNS e avviare una connessione è necessario del tempo. La fisica è imbattibile: una richiesta deve viaggiare nel mondo reale, tramite fili e cavi ottici, per raggiungere un server, quindi la risposta deve tornare indietro. Anche l'origine media con un buon LCP trascorre più di mezzo secondo sul TTFB al suo 75° percentile.
Tuttavia, la disparità del TTFB tra le origini LCP buone e scadenti mostra le opportunità di miglioramento. Per almeno la metà delle origini con LCP scarso, il TTFB p75 di 2.270 millisecondi da solo garantisce quasi che l'LCP p75 non possa essere più veloce del "buono" di 2,5 secondi una determinata soglia. Anche una moderata riduzione percentuale di questo tempo significherebbe un miglioramento significativo dell'LCP.
Anche se non riesci a battere la fisica, ci sono cose che si possono fare. Ad esempio, se i tuoi utenti si trovano spesso in località molto diverse dai server, una CDN può avvicinare i tuoi contenuti.
Per ulteriori informazioni, consulta la guida Ottimizzazione di TTFB.
Ritardo del caricamento delle risorse, il responsabile trascurato LCP lento
Se il TTFB può essere migliorato, ma eventuali miglioramenti sono legati dalla fisica, il ritardo del carico delle risorse può potenzialmente essere eliminato, in pratica è associato solo all'architettura di distribuzione.
Questa sottoparte misura il tempo dall'arrivo del primo byte della risposta HTML (TTFB) all'avvio da parte del browser di una richiesta per l'immagine LCP. Da anni ci siamo concentrati sul tempo necessario per scaricare le immagini LCP, ma spesso abbiamo ignorato il tempo sprecato prima ancora che al browser venisse chiesto di avviare il download.
Un sito mediano con un valore LCP basso passa un tempo quasi quattro volte superiore per iniziare a scaricare l'immagine LCP rispetto a quando la scarica, attendendo 1,3 secondi tra la TTFB e la richiesta dell'immagine. Più della metà del budget LCP di 2,5 secondi è stato speso in una singola sottoparte.
Le catene di dipendenze sono un motivo comune per lunghi ritardi del caricamento. In termini più semplici, c'è una pagina in cui viene caricato un foglio di stile che, dopo che il browser ha configurato il layout, imposta un'immagine di sfondo che diventerà l'LCP. Tutti questi passaggi devono essere eseguiti prima che il browser sappia di dover iniziare a scaricare l'immagine LCP.
Utilizzo dei dati della scansione pubblica di Archivio HTTP, che registra l'"iniziatore" di richieste di rete dal documento HTML a un'immagine LCP, puoi vedere la chiara correlazione tra la lunghezza della catena di richieste e un LCP più lento.
Lo scopo è comunicare al browser il prima possibile quale sarà l'LCP, in modo che possa iniziare a caricarlo, ancor prima che ne sia presente un punto nel layout della pagina. A questo scopo, sono disponibili alcuni strumenti, come un tag <img> classico nel codice HTML, che può essere trovato rapidamente dallo scanner di precaricamento e l'avvio del download, oppure un tag <link rel="preload"> (o un'intestazione HTTP) per le immagini diverse da <img>.
Inoltre, è importante aiutare il browser a determinare a quali risorse dare la priorità. Ciò è particolarmente vero se la pagina fa molte richieste durante il caricamento pagina, in quanto il browser spesso non saprà quale sarà l'elemento LCP finché molte di queste risorse non sono state caricate e non si è verificato il layout. Annotando il probabile elemento LCP con un attributo fetchpriority="high" (e assicurandoti di evitare loading="lazy") consenti al browser di avviare immediatamente il caricamento della risorsa.
Leggi altri consigli sull'ottimizzazione del ritardo del carico.
Ritardo di rendering
Il ritardo del rendering misura il tempo trascorso dal momento in cui l'immagine LCP è stata caricata e pronta nel browser. Tuttavia, per qualche motivo c'è un ritardo prima che venga visualizzata sullo schermo. A volte si tratta di un'attività lunga che blocca il thread principale quando l'immagine è pronta, in altri casi potrebbe trattarsi di una scelta dell'interfaccia utente che rivela un elemento nascosto.
Per un'origine tipica sul web non sembra esserci un'enorme opportunità di ritardo del rendering, ma durante l'ottimizzazione a volte puoi creare un ritardo del rendering pari a quello trascorso in precedenza in altre sottoparti. Ad esempio, se una pagina inizia a precaricare l'immagine LCP in modo che sia disponibile rapidamente, non ci sarà più un lungo ritardo di caricamento, ma se la pagina stessa non è pronta per visualizzare l'immagine (ad esempio da un foglio di stile di blocco della visualizzazione di grandi dimensioni o da un'app di rendering lato client che deve terminare il caricamento di tutto il codice JavaScript prima che sia possibile visualizzare qualcosa), il processo LCP sarà comunque più lento del dovuto e il tempo di attesa ora verrà visualizzato come ritardo del rendering. Questo è il motivo per cui il rendering lato server o l'HTML statico presentano spesso un vantaggio quando si parla di LCP.
Se i tuoi contenuti sono interessati, leggi altri consigli su come ottimizzare il ritardo del rendering.
Seleziona tutte le sottoparti
È chiaro che per ottimizzare efficacemente l'LCP, gli sviluppatori devono osservare il caricamento pagina in modo olistico e non concentrarsi solo sull'ottimizzazione delle immagini. Controlla ogni parte del tempo per la metrica LCP, perché probabilmente le opportunità di miglioramento sono molto maggiori.
Per raccogliere questi dati sul campo, la creazione di attribuzione della libreria di vitals web include i tempi per le sottoparti LCP. Il Report sull'esperienza utente di Chrome (CrUX) non include ancora tutti questi dati, ma contiene voci per TTFB e LCP, quindi è un inizio. Ci auguriamo di includere i dati utilizzati per questo post in CrUX in futuro, quindi continua a seguirci per altre notizie al riguardo.
Per testare a livello locale le sottoparti LCP, prova l'estensione Web Vitals o lo snippet JavaScript in questo articolo. Lighthouse include anche la suddivisione nel suo "elemento Largest Contentful Paint" il controllo. Cerca altri consigli relativi alla sottoparte LCP nel riquadro Prestazioni di DevTools, disponibili a breve.