La metrica Largest Contentful Paint (LCP) di una pagina può essere complicata da migliorare, spesso coinvolgendo più componenti e compromessi. Questo post esamina i dati sul campo dei caricamenti di pagine reali sul web per determinare su quali aspetti gli sviluppatori devono concentrare le proprie attività di ottimizzazione.
Il consiglio classico per LCP: riduci le dimensioni delle immagini.
Per la maggior parte delle pagine sul web, l'elemento LCP è un'immagine. È quindi naturale presumere che il modo migliore per migliorare il valore LCP sia ottimizzare l'immagine LCP.
Nei circa cinque anni dall'introduzione dell'LCP, questo è stato spesso il consiglio principale. Assicurati che le immagini abbiano dimensioni adeguate e siano sufficientemente compresse e, se vuoi, utilizza un formato immagine del 21° secolo. Lighthouse dispone addirittura di tre diversi controlli per fornire questi suggerimenti.
Uno dei motivi per cui questo è un consiglio così comune è che i byte eccessivi sono facili da misurare e gli strumenti di compressione delle immagini sono facili da suggerire. A seconda delle pipeline di compilazione e di deployment, potrebbe anche essere facile da implementare.
Se è così, fallo. Inviare meno byte agli utenti è quasi sempre una buona idea. Sul web sono presenti molti siti che continuano a pubblicare immagini inutilmente grandi che potrebbero essere compresse anche con una compressione di base.
Tuttavia, quando abbiamo iniziato a esaminare i dati sul rendimento sul campo per gli utenti in Chrome per capire dove viene in genere speso il tempo necessario per l'LCP, abbiamo scoperto che il tempo di download delle immagini non è quasi mai il collo di bottiglia.
Invece, altri aspetti dell'LCP rappresentano un problema molto più grande.
Suddivisione delle componenti secondarie LCP
Per capire quali erano le aree di opportunità più importanti per migliorare il valore LCP, abbiamo esaminato i dati delle sottoparti LCP, come descritto in Ottimizzare il valore LCP.
Sebbene ogni pagina e ogni framework possa adottare un approccio diverso per il caricamento e la visualizzazione di ciò che diventa l'elemento LCP della pagina, ogni pagina può essere suddivisa in queste sottoparti:
Riportando quanto indicato nell'articolo, le sottoparti sono:
- Tempo di risposta (TTFB)
- Il tempo che intercorre tra l'avvio del caricamento della pagina da parte dell'utente e il momento in cui il browser riceve il primo byte della risposta del documento HTML.
- Ritardo del caricamento delle risorse
- Il tempo che intercorre tra il TTFB e il momento in cui il browser inizia a caricare la risorsa LCP. Se
l'elemento LCP non richiede il caricamento di risorse per il rendering, questo valore è
0
. - Durata caricamento risorse
- La durata del tempo necessario per caricare la risorsa LCP stessa. Se l'elemento LCP
non richiede il caricamento di una risorsa per il rendering, questo valore è
0
. - Ritardo di rendering dell'elemento
- Il tempo che intercorre tra il termine del caricamento della risorsa LCP e il completamento del rendering dell'elemento LCP.
Dati sul rendimento della navigazione reale
Classificazione LCP | TTFB (ms) | Ritardo di caricamento delle immagini (ms) | Durata del caricamento delle immagini (ms) | Ritardo di rendering (ms) |
---|---|---|---|---|
Buono | 600 | 350 | 160 | 230 |
Richiedono miglioramenti | 1360 | 720 | 270 | 310 |
Scadente | 2270 | 1290 | 350 | 360 |
Per questo post, abbiamo utilizzato i dati delle navigazioni nelle pagine con un'immagine LCP di risorse secondarie in Chrome per esaminare le sottoparti LCP. Abbiamo già esaminato questo tipo di dati, ma mai da dati sul campo per capire dove gli utenti reali trascorrono il tempo mentre aspettano l'LCP di una pagina.
Come per Core Web Vitals, abbiamo preso il 75° percentile (p75) di ogni componente LCP per ogni origine nel set di dati CrUX, ottenendo quattro distribuzioni di valori p75 (uno per ogni componente). Per riepilogare queste distribuzioni, abbiamo preso la mediana di questi valori in tutte le origini per ciascuna delle quattro sottoparti LCP.
Infine, suddividiamo le origini in bucket in base al fatto che abbiano un LCP "buono", "richiede miglioramenti" o "scadente" al 75° percentile. In questo modo è più facile capire cosa distingue un'origine con un buon LCP da un'origine con un LCP scadente.
Riduci le dimensioni dell'immagine LCP? Questa volta con i dati
La durata del caricamento è la misura del tempo necessario per recuperare la risorsa LCP, in questo caso un'immagine. Questo tempo è generalmente proporzionale al numero di byte dell'immagine, da qui tutti i consigli sul rendimento per ridurre questo numero di byte.
Se osserviamo dove viene impiegato il tempo nei grafici precedenti, una cosa che salta all'occhio è che non viene impiegato molto tempo per il caricamento delle immagini. In effetti, è la sottoparte LCP più breve in tutti i bucket LCP. La durata del caricamento è più lunga per le origini con un LCP basso rispetto a quelle con un LCP elevato, ma non è ancora lì che viene speso il tempo.
La maggior parte delle origini con un valore LCP basso spende meno del 10% del tempo LCP p75 per scaricare l'immagine LCP.
Sì, devi assicurarti che le immagini siano ottimizzate, ma questa è solo una parte del miglioramento del LCP. Da questi dati è chiaro che, per l'origine tipica sul web, i potenziali guadagni in millisecondi per l'LCP sono ridotti, indipendentemente dalla complessità dello schema di compressione.
Un'ultima sorpresa: in passato, le durate di caricamento lente erano in genere attribuite ai dispositivi mobili e alla qualità delle reti mobili. In passato, avremmo potuto aspettarci che uno smartphone medio impieghi più volte il tempo di un computer su una connessione cablata per scaricare la stessa immagine. I dati suggeriscono che non è più così. Per le origini con LCP scadente, la durata media del caricamento delle immagini p75 è solo del 20% più lenta sui dispositivi mobili rispetto ai computer.
Tempo di risposta (TTFB)
Per le navigazioni che effettuano una richiesta di rete, il TTFB richiede sempre del tempo. La ricerca DNS e l'avvio di una connessione richiedono tempo. E non puoi battere la fisica: una richiesta deve attraversare il mondo reale su cavi e cavi ottici per raggiungere un server, quindi la risposta deve fare il percorso inverso. Anche l'origine mediana con un buon valore LCP impiega più di mezzo secondo per il TTFB al 75° percentile.
Tuttavia, la disparità del TTFB tra le origini LCP buone e scarse indica un'opportunità di miglioramento. Per almeno la metà delle origini con LCP scadente, il TTFB p75 di 2270 millisecondi da solo garantisce quasi che il LCP p75 non possa essere più veloce della soglia "buona" di 2,5 secondi. Anche una moderata riduzione percentuale di questo tempo significherebbe un miglioramento significativo dell'LCP.
Potresti non essere in grado di battere le leggi della fisica, ma ci sono cose che puoi fare. Ad esempio, se i tuoi utenti si trovano spesso in una località molto diversa dai tuoi server, una CDN può avvicinare i tuoi contenuti a loro.
Per saperne di più, consulta la guida all'ottimizzazione del TTFB.
Ritardo del caricamento delle risorse, il colpevole principale del LCP lento trascurato
Se il tempo di risposta del server può essere migliorato, ma eventuali miglioramenti sono vincolati dalla fisica, il ritardo di caricamento delle risorse può essere potenzialmente eliminato, in pratica solo vincolato dall'architettura di pubblicazione.
Questa parte misura il tempo dall'arrivo del primo byte della risposta HTML (TTFB) al momento in cui il browser avvia una richiesta per l'immagine LCP. Da anni ci concentriamo sul tempo necessario per scaricare le immagini LCP, ma spesso abbiamo ignorato il tempo perso prima ancora che al browser venga chiesto di avviare il download.
Il sito mediano con un LCP scadente impiega quasi quattro volte più tempo per iniziare a scaricare l'immagine LCP rispetto al tempo necessario per scaricarla effettivamente, ovvero 1,3 secondi tra il TTFB e la richiesta di immagine. Si tratta di più della metà del budget LCP di 2,5 secondi speso in una singola parte secondaria.
Le catene di dipendenze sono una causa comune di lunghi ritardi di caricamento. Un esempio più semplice è una pagina che carica un foglio di stile che, dopo il layout del browser, imposta un'immagine di sfondo che diventerà l'LCP. Tutti questi passaggi devono essere completati prima che il browser sappia di dover iniziare a scaricare l'immagine LCP.
Utilizzando i dati pubblici della scansione di HTTP Archive, che registrano la catena di richieste di rete "iniziatore" dal documento HTML a un'immagine LCP, puoi vedere la chiara correlazione tra la lunghezza della catena di richieste e un LCP più lento.
L'importante è comunicare al browser il prima possibile quale sarà l'LCP in modo che possa iniziare a caricarla, anche prima che sia presente un punto apposito nel layout della pagina. Esistono alcuni strumenti disponibili per farlo, ad esempio un tag <img>
classico nel codice HTML in modo che lo scanner di precaricamento possa trovarlo rapidamente e iniziare a scaricarlo oppure un tag <link rel="preload">
(o un'intestazione HTTP) per le immagini che non saranno <img>
.
È importante anche aiutare il browser a determinare le risorse a cui dare la priorità. Questo è particolarmente vero se la tua pagina effettua molte richieste durante il caricamento, in quanto spesso il browser non sa quale sarà l'elemento LCP finché non sono state caricate molte di queste risorse e non è stato eseguito il layout. Se annoti l'elemento LCP probabile con un attributo fetchpriority="high"
(e fai in modo di evitare loading="lazy"
), il browser inizia a caricare immediatamente la risorsa.
Leggi ulteriori consigli su come ottimizzare il ritardo di caricamento.
Ritardo di rendering
Il ritardo di rendering misura il tempo che intercorre tra il momento in cui l'immagine LCP è caricata e pronta nel browser e quello in cui viene visualizzata sullo schermo per qualche motivo. A volte si tratta di un'attività lunga che blocca il thread principale quando l'immagine è pronta, in altri casi potrebbe essere una scelta dell'interfaccia utente per rivelare un elemento nascosto.
Per l'origine tipica sul web non sembra esserci un'enorme opportunità di ritardo nel rendering, ma durante l'ottimizzazione a volte puoi creare un ritardo nel rendering dal tempo precedentemente impiegato in altre parti secondarie. 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 grandi dimensioni che blocca il rendering o da un'app con rendering lato client che deve completare il caricamento di tutto il codice JavaScript prima che qualsiasi elemento possa essere visualizzato, il tempo di attesa verrà visualizzato come ritardo di rendering. Ecco perché il rendering lato server o l'HTML statico hanno spesso un vantaggio in termini di LCP.
Se i tuoi contenuti sono interessati, leggi ulteriori consigli su come ottimizzare il ritardo di rendering.
Controlla tutti questi componenti secondari
È chiaro che, per ottimizzare efficacemente il LCP, gli sviluppatori devono esaminare il caricamento della pagina in modo olistico e non concentrarsi solo sull'ottimizzazione delle immagini. Controlla ogni parte del tempo di caricamento LCP, perché probabilmente ci sono opportunità di miglioramento molto maggiori.
Per raccogliere questi dati sul campo, la compilazione dell'attribuzione della libreria web-vitals 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 buon inizio. Ci auguriamo di includere in futuro i dati utilizzati per questo post in CrUX, quindi continua a seguirci per altre notizie in merito.
Per testare localmente le componenti secondarie LCP, prova l'estensione Web Vitals o lo snippet JavaScript in questo articolo. Lighthouse include anche la suddivisione nell'audit "Elemento Largest Contentful Paint". Consulta altri consigli sulle componenti secondarie LCP nel riquadro Rendimento di DevTools, disponibile a breve.