Una guida passo passo su come suddividere l'LCP e identificare le aree chiave da migliorare.
Data di pubblicazione: 30 aprile 2020
Largest Contentful Paint (LCP) è una delle tre metriche Core Web Vitals e indica la velocità di caricamento dei contenuti principali di una pagina web. In particolare, LCP misura il tempo che intercorre tra l'inizio del caricamento della pagina da parte dell'utente e la visualizzazione nell'area visibile dell'immagine o del blocco di testo più grande.
Per offrire una buona esperienza utente, i siti dovrebbero fare in modo di avere un valore LCP pari o inferiore a 2,5 secondi per almeno il 75% delle visite alla pagina.
Diversi fattori possono influire sulla velocità con cui il browser può caricare e visualizzare una pagina web e i ritardi in uno di questi fattori possono avere un impatto significativo sull'LCP.
È raro che una correzione rapida a una singola parte di una pagina generi un miglioramento significativo della metrica LCP. Per migliorare il valore di questa metrica, devi esaminare l'intero processo di caricamento e assicurarti che ogni passaggio sia ottimizzato.
Informazioni sulla metrica LCP
Prima di ottimizzare l'LCP, gli sviluppatori devono cercare di capire se hanno un problema di LCP e la sua entità.
L'LCP può essere misurata in diversi strumenti e non tutti la misurano nello stesso modo. Per comprendere la metrica LCP degli utenti reali, dobbiamo guardare a ciò che stanno vivendo gli utenti reali, piuttosto che quello che mostra uno strumento basato su lab come Lighthouse o i test locali. Questi strumenti basati sui lab possono fornire moltissime informazioni da spiegare e aiutarti a migliorare l'LCP, ma tieni presente che i soli test di laboratorio potrebbero non essere del tutto rappresentativi dell'esperienza effettiva degli utenti.
I dati LCP basati su utenti reali possono essere visualizzati dagli strumenti di monitoraggio degli utenti reali (RUM) installati su un sito o utilizzando il Report sull'esperienza utente di Chrome (CrUX), che raccoglie dati anonimi da utenti reali di Chrome per milioni di siti web.
Utilizzare i dati LCP di CrUX di Chrome DevTools
Il pannello Rendimento di Chrome DevTools mostra la tua esperienza LCP locale accanto all'LCP CrUX della pagina o dell'origine nella visualizzazione delle metriche in tempo reale.
Applicando i dati dei campi al riquadro Rendimento, puoi valutare se una pagina presenta problemi LCP per gli utenti reali e adattare le impostazioni dell'ambiente locale per riprodurli e delinearli meglio.
Utilizzare i dati LCP di CrUX di PageSpeed Insights
PageSpeed Insights dà accesso ai dati di CrUX nella sezione superiore denominata Scopri cosa stanno vivendo i tuoi utenti reali. Dati più dettagliati basati su test di laboratorio sono disponibili nella sezione in basso denominata Diagnostica i problemi di prestazioni. Se i dati di CrUX sono disponibili per il tuo sito web, concentrati sempre prima sui dati utente reali.
PageSpeed Insights mostra fino a quattro diversi dati CrUX:
- Dati mobile per questo URL
- Dati desktop per questo URL
- Dati mobili per l'intera Origin
- Dati desktop per l'intera Origin
Puoi attivarli e disattivarli nei controlli in alto e in alto a destra in questa sezione. Se un URL non dispone di dati sufficienti per essere mostrato a livello di URL, ma dispone di dati per l'origine, PageSpeed Insights mostra sempre i dati dell'origine.
Il valore LCP per l'intera origine può essere molto diverso da quello di una singola pagina a seconda di come viene caricato nella pagina rispetto alle altre pagine dell'origine. Inoltre, può essere influenzato dal modo in cui i visitatori accedono a queste pagine. Le home page tendono a essere visitate da nuovi utenti e quindi potrebbero essere caricate "a freddo", senza contenuti memorizzati nella cache, e quindi sono spesso le pagine più lente di un sito web.
Esaminare le quattro diverse categorie di dati di CrUX può aiutarti a capire se un problema LCP è specifico di questa pagina o se si tratta di un problema più generale a livello di sito. Analogamente, può mostrare i tipi di dispositivi che hanno problemi di LCP.
Utilizzo di metriche supplementari di PageSpeed Insights CrUX
Chi vuole ottimizzare LCP deve utilizzare anche i tempi di First Contentful Paint (FCP) e Time to First Byte (TTFB), che sono ottime metriche di diagnostica che possono fornire informazioni preziose su LCP.
Il TTFB è il tempo che intercorre tra il momento in cui il visitatore inizia a visitare una pagina (ad esempio facendo clic su un link) e il momento in cui vengono ricevuti i primi byte del documento HTML. Un TTFB elevato può rendere difficile o addirittura impossibile raggiungere un LCP di 2, 5 secondi.
Un TTFB elevato può essere dovuto a più reindirizzamenti del server, visitatori lontani dal server del sito più vicino, visitatori in condizioni di rete scadenti o impossibilità di utilizzare i contenuti memorizzati nella cache a causa dei parametri di query.
Una volta avviato il rendering di una pagina, potrebbe essere visualizzata una schermata iniziale (ad esempio, il colore di sfondo), seguita da alcuni contenuti (ad esempio, l'intestazione del sito). L'aspetto dei contenuti iniziali viene misurato tramite FCP. Il delta tra il CPM e altre metriche può essere molto significativo.
Un delta elevato tra TTFB e FCP potrebbe indicare che il browser deve scaricare molti asset che bloccano il rendering. Può anche essere un segno che deve essere completato molto lavoro per visualizzare contenuti significativi, un classico segno di un sito che si basa molto sul rendering lato client.
Un delta elevato tra FCP e LCP indica che la risorsa LCP non è immediatamente disponibile per l'assegnazione della priorità da parte del browser (ad esempio, testo o immagini gestite da JavaScript anziché essere disponibili nell'HTML iniziale) oppure che il browser sta completando altri lavori prima di poter visualizzare i contenuti LCP.
Utilizzare i dati di Lighthouse di PageSpeed Insights
La sezione Lighthouse di PageSpeed Insights offre alcune indicazioni per migliorare il tempo di caricamento della prima pagina, ma prima devi verificare se il tempo di caricamento della prima pagina indicato è in linea con i dati utente reali forniti da CrUX. Se Lighthouse e CrUX non sono d'accordo, è probabile che CrUX fornisca un quadro più preciso della tua esperienza utente. Prima di intervenire, assicurati che i dati di CrUX riguardino la tua pagina e non l'origine completa.
Se sia Lighthouse sia CrUX mostrano valori LCP che richiedono miglioramenti, la sezione Lighthouse può fornire indicazioni preziose su come migliorare questo valore. Utilizza il filtro LCP per mostrare solo i controlli pertinenti al LCP come segue:
Oltre alle Opportunità di miglioramento, sono disponibili informazioni di Diagnostica che possono fornire ulteriori informazioni per aiutarti a diagnosticare il problema. La diagnostica dell'elemento Largest Contentful Paint mostra una suddivisione utile dei vari tempi che compongono l'LCP:
Ci occuperemo di queste sottopartizioni.
Suddivisione LCP
L'ottimizzazione per l'LCP può essere un'operazione più complessa quando PageSpeed Insights non fornisce la risposta su come migliorare questa metrica. In genere, è meglio suddividere le attività complesse in attività più piccole e gestibili e affrontarle separatamente.
Questa sezione illustra una metodologia su come suddividere l'LCP nelle sue sottoparti più critiche e quindi presentare consigli e best practice specifici su come ottimizzare ogni parte.
La maggior parte dei caricamenti delle pagine include in genere una serie di richieste di rete, ma per identificare le opportunità di miglioramento dell'LCP, dovresti iniziare con l'analisi di due soli elementi:
- Il documento HTML iniziale
- La risorsa LCP (se applicabile)
Sebbene altre richieste sulla pagina possano influire sulla LCP, queste due richieste, in particolare i momenti di inizio e fine della risorsa LCP, indicano se la pagina è ottimizzata o meno per la LCP.
Per identificare la risorsa LCP, puoi utilizzare gli strumenti per sviluppatori (come PageSpeed Insights discusso in precedenza, Chrome DevTools o WebPageTest) per determinare l'elemento LCP. Da qui puoi trovare (di nuovo, se applicabile) l'URL caricato dall'elemento in una struttura a cascata di rete di tutte le risorse caricate dalla pagina.
Ad esempio, la seguente visualizzazione mostra queste risorse evidenziate in un diagramma a cascata della rete da un caricamento di pagina tipico, in cui l'elemento LCP richiede una richiesta di immagine per il rendering.
Per una pagina ben ottimizzata, è consigliabile iniziare a caricare la richiesta della risorsa LCP il prima possibile e il rendering dell'elemento LCP deve avvenire il più rapidamente possibile al termine del caricamento della risorsa LCP. Per capire se una determinata pagina segue o meno questo principio, puoi suddividere il tempo LCP totale nelle seguenti sottoparti:
- Time to First Byte (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 la TTFB e l'avvio del caricamento della risorsa LCP da parte del browser. Se l'elemento LCP non richiede il caricamento di una risorsa per il rendering (ad esempio, se l'elemento è un nodo di testo visualizzato con un carattere di sistema), questo tempo è 0.
- Durata del caricamento delle 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.
L'LCP di ogni pagina è composto da queste quattro sottocategorie. Non sono presenti spazi o sovrapposizioni tra loro e si sommano al tempo LCP completo.
Il valore LCP di ogni singola pagina può essere suddiviso in queste quattro parti. Non ci sono sovrapposizioni o spazi tra di loro. Insieme, corrispondono al tempo LCP completo.
Quando ottimizzi l'LCP, è utile provare a ottimizzare queste sottoparti singolarmente. Tuttavia, è importante tenere presente che devi ottimizzarli tutti. In alcuni casi, un'ottimizzazione applicata a una parte non migliora il LCP, ma sposta il tempo risparmiato su un'altra parte.
Ad esempio, nella struttura a cascata della rete precedente, se riduci le dimensioni del file dell'immagine comprimendola di più o passando a un formato più ottimale (ad esempio AVIF o WebP), la durata del caricamento delle risorse si riduce, ma l'LCP non migliora perché il tempo si sposta semplicemente nella sottoparte Ritardo di rendering dell'elemento:
Questo accade perché, in questa pagina, l'elemento LCP è nascosto fino al termine del caricamento del codice JavaScript, dopodiché tutto viene visualizzato contemporaneamente.
Questo esempio serve a illustrare il fatto che devi ottimizzare tutte queste componenti secondarie per ottenere i migliori risultati LCP.
Tempi ottimali delle sottoparti
Per ottimizzare ogni componente dell'LCP, è importante capire qual è la suddivisione ideale di queste componenti in una pagina ben ottimizzata.
Delle quattro sottoparti, due contengono la parola "delay" nel nome. Questo è un indizio che ti suggerisce di avvicinarti il più possibile a zero. Le altre due parti richiedono richieste di rete, che per loro natura richiedono tempo.
Tieni presente che queste suddivisioni in base al tempo sono linee guida, non regole rigide. Se i tempi LCP delle tue pagine sono costantemente entro 2,5 secondi, non ha molta importanza quali siano le proporzioni relative. Ma se trascorri molto tempo inutile in una delle due porzioni di ritardo, sarà molto difficile raggiungere costantemente il target di 2,5 secondi.
Un buon modo per comprendere la suddivisione del tempo LCP è:
- La maggior parte del tempo LCP dovrebbe essere dedicata al caricamento del documento HTML e della sorgente LCP.
- Qualsiasi momento prima dell'LCP in cui una di queste due risorse non viene caricata rappresenta un'opportunità di miglioramento.
Come ottimizzare ogni parte
Ora che sai come devono essere suddivisi i tempi delle sottoparti dell'LCP in una pagina ben ottimizzata, puoi iniziare a ottimizzare le tue pagine.
Le quattro sezioni successive presenteranno consigli e best practice su come ottimizzare ciascuna parte. Vengono presentati in ordine, a partire dalle ottimizzazioni che hanno maggiori probabilità di avere un impatto significativo.
1. Elimina il ritardo del carico delle risorse
Lo scopo di questo passaggio è assicurarsi che la risorsa LCP inizi a caricarsi il prima possibile. Sebbene in teoria il momento più precoce in cui una risorsa potrebbe iniziare a caricarsi sia immediatamente dopo il TTFB, in pratica c'è sempre un po' di ritardo prima che i browser inizino effettivamente a caricare le risorse.
Una buona regola empirica è che la risorsa LCP deve iniziare a caricarsi contemporaneamente alla prima risorsa caricata dalla pagina. In altre parole, se la risorsa LCP inizia a caricarsi più tardi della prima risorsa, significa che c'è margine di miglioramento.
In generale, esistono due fattori che influiscono sulla velocità di caricamento di una risorsa LCP:
- Quando viene rilevata la risorsa.
- La priorità assegnata alla risorsa.
Ottimizza quando la risorsa viene rilevata
Per assicurarti che la risorsa LCP inizi a caricarsi il prima possibile, è fondamentale che sia rilevabile nella risposta del documento HTML iniziale dallo scanner di precaricamento del browser. Ad esempio, nei seguenti casi il browser può rilevare la risorsa LCP analizzando la risposta del documento HTML:
- L'elemento LCP è un elemento
<img>e i suoi attributisrcosrcsetsono presenti nel markup HTML iniziale. - L'elemento LCP richiede un'immagine di sfondo CSS, ma questa immagine viene precaricata utilizzando
<link rel="preload">nel markup HTML (o utilizzando un'intestazioneLink). - L'elemento LCP è un nodo di testo che richiede un carattere web per il rendering e il carattere viene caricato utilizzando
<link rel="preload">nel markup HTML (o utilizzando un'intestazioneLink).
Di seguito sono riportati alcuni esempi in cui non è possibile rilevare la risorsa LCP durante la scansione della risposta del documento HTML:
- L'elemento LCP è un
<img>che viene aggiunto alla pagina in modo dinamico utilizzando JavaScript. - L'elemento LCP viene caricato in modo lazy con una libreria JavaScript che nasconde i suoi attributi
srcosrcset(spesso comedata-srcodata-srcset). - L'elemento LCP richiede un'immagine di sfondo CSS.
In ognuno di questi casi, il browser deve eseguire lo script o applicare il foglio di stile, che di solito comporta l'attesa del completamento delle richieste di rete, prima di poter rilevare la risorsa LCP e iniziare a caricarla. Questo non è mai ottimale.
Per eliminare i ritardi di caricamento delle risorse non necessari, la risorsa LCP deve essere rilevabile dal codice sorgente HTML. Se la risorsa viene richiamata solo da un file CSS o JavaScript esterno, la risorsa LCP deve essere precaricata con una priorità di recupero elevata, ad esempio:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
Ottimizza la priorità assegnata alla risorsa
Anche se la risorsa LCP è rilevabile dal markup HTML, ancora potrebbe non iniziare a caricarsi prima della prima risorsa. Questo può accadere se l'euristica di priorità dello scanner di precaricamento del browser non riconosce che la risorsa è importante o se determina che altre risorse sono più importanti.
Ad esempio, puoi ritardare l'immagine LCP utilizzando HTML se imposti loading="lazy" nell'elemento <img>. Se utilizzi il caricamento lento, la risorsa non verrà caricata finché il layout non avrà confermato che l'immagine è nel viewport e, di conseguenza, il caricamento potrebbe iniziare più tardi rispetto a quanto avverrebbe in caso contrario.
Anche senza il caricamento lento, le immagini non vengono caricate inizialmente con la massima priorità dai browser perché non sono risorse che bloccano il rendering. Puoi indicare al browser quali risorse sono più importanti utilizzando l'attributo fetchpriority per le risorse che potrebbero trarre vantaggio da una priorità più alta:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Ti consigliamo di impostare fetchpriority="high" su un elemento <img> se ritieni che sia probabile che si tratti dell'elemento LCP della tua pagina. Tuttavia, impostare una priorità elevata su più di una o due immagini rende l'impostazione della priorità non utile per ridurre il valore LCP.
Puoi anche abbassare la priorità delle immagini che potrebbero trovarsi all'inizio della risposta del documento, ma che non sono visibili a causa dello stile, ad esempio le immagini nelle diapositive del carosello che non sono visibili all'avvio:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
La riassegnazione della priorità a determinate risorse può consentire di avere più larghezza di banda per le risorse che ne hanno più bisogno, ma fai attenzione. Controlla sempre la priorità delle risorse in DevTools e testa le modifiche con gli strumenti di laboratorio e sul campo.
Dopo aver ottimizzato la priorità e il momento di rilevamento della risorsa LCP, la struttura a cascata della rete dovrebbe avere il seguente aspetto (con la risorsa LCP che inizia contemporaneamente alla prima risorsa):
2. Elimina il ritardo di rendering degli elementi
L'obiettivo in questo passaggio è garantire che l'elemento LCP possa essere visualizzato immediatamente al termine del caricamento della risorsa, indipendentemente da quando si verifica.
Il motivo principale per cui l'elemento LCP non potrebbe essere visualizzato immediatamente al termine del caricamento della risorsa è che il rendering è bloccato per qualche altro motivo:
- Il rendering dell'intera pagina è bloccato a causa di stili o script sincroni in
<head>che sono ancora in fase di caricamento. - Il caricamento della risorsa LCP è terminato, ma l'elemento LCP non è stato ancora aggiunto al DOM (l'elemento è in attesa del caricamento di codice JavaScript).
- L'elemento è nascosto da un altro codice, ad esempio una libreria di test A/B che sta ancora determinando a quale esperimento deve partecipare l'utente.
- Il thread principale è bloccato a causa di attività lunghe e il lavoro di rendering deve attendere il completamento di queste attività.
Le sezioni seguenti spiegano come risolvere le cause più comuni di ritardo di rendering degli elementi non necessari.
Riduci o inserisci in linea gli stili CSS che bloccano il rendering
Le stylesheet caricate dal markup HTML bloccheranno il rendering di tutti i contenuti che seguono, il che è positivo, poiché in genere non vuoi eseguire il rendering di HTML senza stile. Tuttavia, se lo stile è così grande che il suo caricamento richiede molto più tempo rispetto alla risorsa LCP, impedirà il rendering dell'elemento LCP, anche dopo il completamento del caricamento della risorsa, come mostrato in questo esempio:
Per risolvere il problema, puoi:
- incorporare il foglio di stile nel codice HTML per evitare la richiesta di rete aggiuntiva; oppure
- riduci le dimensioni del foglio di stile.
In generale, l'incorporamento del foglio di stile è consigliato solo se il foglio di stile è di dimensioni ridotte, in quanto i contenuti incorporati nel codice HTML non possono trarre vantaggio dalla memorizzazione nella cache nei caricamenti di pagina successivi. Se una intestazione CSS è così grande che richiede più tempo per il caricamento rispetto alla risorsa LCP, è improbabile che sia una buona candidata per l'inserimento in linea.
Nella maggior parte dei casi, il modo migliore per assicurarsi che il foglio di stile non blocchi il rendering dell'elemento LCP è ridurne le dimensioni in modo che sia più piccolo della risorsa LCP. Questo dovrebbe garantire che non sia un collo di bottiglia per la maggior parte delle visite.
Ecco alcuni consigli per ridurre le dimensioni del foglio di stile:
- Rimuovi CSS inutilizzato: utilizza Chrome DevTools per trovare le regole CSS che non vengono utilizzate e che possono essere potenzialmente rimosse (o differite).
- Rimandare il CSS non critico: suddividi lo style sheet in stili necessari per il caricamento iniziale della pagina e in stili che possono essere caricati in modo lazy.
- Minimizza e comprime i CSS: per gli stili fondamentali, assicurati di ridurre al massimo le dimensioni di trasferimento.
Rimandare o inserire in linea il codice JavaScript che blocca la visualizzazione
Non è quasi mai necessario aggiungere script sincroni (script senza gli attributi async o defer) al <head> delle pagine e questa operazione avrà quasi sempre un impatto negativo sul rendimento.
Nei casi in cui il codice JavaScript debba essere eseguito il prima possibile durante il caricamento della pagina, è meglio inserirlo in linea in modo che il rendering non venga ritardato in attesa di un'altra richiesta di rete. Tuttavia, come per gli stili, devi inserire gli script in linea solo se sono molto piccoli.
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>Utilizzare il rendering lato server
Il rendering lato server (SSR) è il processo di esecuzione della logica dell'applicazione lato client sul server e di risposta alle richieste di documenti HTML con il markup HTML completo.
Dal punto di vista dell'ottimizzazione del LCP, l'SSR presenta due vantaggi principali:
- Le risorse immagine saranno rilevabili dal codice sorgente HTML (come descritto nel passaggio 1 precedente).
- I contenuti della pagina non richiedono richieste JavaScript aggiuntive per essere visualizzati.
Lo svantaggio principale dell'SSR è che richiede tempi di elaborazione del server aggiuntivi, il che può rallentare il TTFB. In genere, questo compromesso vale la pena perché i tempi di elaborazione del server sono sotto il tuo controllo, mentre le funzionalità di rete e del dispositivo degli utenti non lo sono.
Un'opzione simile al rendering lato server è la generazione di siti statici (SSG) o il prerendering. Si tratta del processo di generazione delle pagine HTML in un passaggio di compilazione anziché su richiesta. Se il prerendering è possibile con la tua architettura, in genere è una scelta migliore per le prestazioni.
Suddividi le attività lunghe
Anche se hai seguito i consigli precedenti e il codice JavaScript non blocca il rendering né è responsabile del rendering degli elementi, può comunque ritardare il LCP.
Il motivo più comune è che le pagine caricano file JavaScript di grandi dimensioni, che devono essere analizzati ed eseguiti nel thread principale del browser. Ciò significa che, anche se la risorsa immagine è stata completamente scaricata, potrebbe comunque essere necessario attendere il termine dell'esecuzione di uno script non correlato prima che possa essere visualizzata.
Oggi tutti i browser visualizzano le immagini nel thread principale, il che significa che tutto ciò che blocca il thread principale può anche portare a ritardo di rendering degli elementi non necessario.
3. Riduci la durata del carico delle risorse
Lo scopo di questo passaggio è ridurre il tempo impiegato per trasferire i byte della risorsa sulla rete al dispositivo dell'utente. In genere, esistono quattro modi per farlo:
- Riduci le dimensioni della risorsa.
- Riduci la distanza che deve percorrere la risorsa.
- Riduci la concorrenza per la larghezza di banda della rete.
- Elimina completamente l'ora della rete.
Riduci le dimensioni della risorsa
La risorsa LCP di una pagina (se presente) sarà un'immagine o un carattere web. Le seguenti guide descrivono in dettaglio come ridurre le dimensioni di entrambi:
- Pubblicare le dimensioni delle immagini ottimali
- Utilizzare formati delle immagini moderni
- Comprimi le immagini
- Ridurre le dimensioni dei caratteri web
Riduci la distanza che la risorsa deve percorrere
Oltre a ridurre le dimensioni di una risorsa, puoi anche ridurre i tempi di caricamento posizionando i server il più vicino possibile ai tuoi utenti. Il modo migliore per farlo è utilizzare una rete CDN (Content Delivery Network).
Le CDN di immagini in particolare sono particolarmente utili perché non solo riducono la distanza che la risorsa deve percorrere, ma riducono anche le dimensioni della risorsa, implementando automaticamente tutti i consigli per la riduzione delle dimensioni precedenti.
Ridurre la concorrenza per la larghezza di banda della rete
Anche se hai ridotto le dimensioni della risorsa e la distanza che deve percorrere, il caricamento di una risorsa può comunque richiedere molto tempo se stai caricando molte altre risorse contemporaneamente. Questo problema è noto come concorrenza sulla rete.
Se hai assegnato alla risorsa LCP un valore fetchpriority elevato e hai iniziato a caricarla il prima possibile, il browser farà del suo meglio per impedire alle risorse con priorità inferiore di competere con essa. Tuttavia, se carichi molte risorse con un valore fetchpriority elevato o se carichi semplicemente molte risorse in generale, la velocità di caricamento della risorsa LCP potrebbe essere interessata.
Eliminare completamente l'ora della rete
Il modo migliore per ridurre la durata del caricamento delle risorse è eliminare completamente la rete dal processo. Se pubblichi le risorse con un criterio di controllo della cache efficiente, i visitatori che richiedono queste risorse una seconda volta le riceveranno dalla cache, riducendo la durata del caricamento delle risorse a zero.
Se la risorsa LCP è un carattere web, oltre a ridurre le dimensioni dei caratteri web, dovresti anche valutare se è necessario bloccare il rendering al carico di risorse dei caratteri web. Se imposti un valore font-display diverso da auto o block, il testo sarà sempre visibile durante il caricamento e l'LCP non verrà bloccato in seguito a un'ulteriore richiesta di rete.
Infine, se la risorsa LCP è di piccole dimensioni, potrebbe avere senso incorporare le risorse come URL di dati, eliminando così anche la richiesta di rete aggiuntiva. Tuttavia, l'utilizzo degli URL dei dati presenta delle limitazioni perché le risorse non possono essere memorizzate nella cache e, in alcuni casi, possono verificarsi ritardi di rendering più lunghi a causa del costo di decodifica aggiuntivo.
4. Riduci il tempo per il primo byte
Lo scopo di questo passaggio è pubblicare il codice HTML iniziale il più rapidamente possibile. Questo passaggio è elencato per ultimo perché spesso è quello su cui gli sviluppatori hanno il minor controllo. Tuttavia, è anche uno dei passaggi più importanti perché influisce direttamente su ogni passaggio successivo. Non può succedere nulla sul frontend finché il backend non fornisce quel primo byte di contenuto, quindi qualsiasi cosa tu possa fare per velocizzare il TTFB migliorerà anche ogni altra metrica di carico.
Una causa comune di un TTFB lento per un sito altrimenti veloce è rappresentata dai visitatori che arrivano tramite più reindirizzamenti, ad esempio da annunci o link abbreviati. Riduci sempre al minimo il numero di reindirizzamenti che un visitatore deve attendere.
Un'altra causa comune è quando i contenuti memorizzati nella cache non possono essere utilizzati da un server edge CDN e tutte le richieste devono essere reindirizzate al server di origine. Questo può accadere se i visitatori utilizzano parametri URL univoci per l'analisi, anche se non generano pagine diverse.
Per indicazioni specifiche sull'ottimizzazione del TTFB, consulta la guida per l'ottimizzazione del TTFB.
Monitora la suddivisione LCP in JavaScript
Le informazioni sui tempi di tutte le componenti secondarie LCP discusse in precedenza sono disponibili in JavaScript tramite una combinazione delle seguenti API di rendimento:
Il vantaggio di calcolare questi valori di tempo in JavaScript è che puoi inviarli a un provider di analisi o registrarli agli strumenti per sviluppatori per facilitare il debug e l'ottimizzazione.
Ad esempio, il seguente screenshot utilizza il metodo performance.measure() dell'API User Timing per aggiungere barre alla traccia Tempi nel riquadro Prestazioni di Chrome DevTools.
Le visualizzazioni nella traccia Tempi sono particolarmente utili se esaminate insieme alle tracce Rete e Thread principale, perché consentono di capire a colpo d'occhio cos'altro accade sulla pagina in questi intervalli di tempo.
Oltre a visualizzare le sottoparti LCP nella traccia di temporizzazione, puoi anche usare JavaScript per calcolare la percentuale di ogni sottoparte rispetto al tempo LCP totale. Con queste informazioni, puoi determinare se le tue pagine soddisfano le suddivisioni percentuali consigliate descritte in precedenza.
Questo screenshot mostra un esempio che registra il tempo totale di ogni sottoparte LCP e la relativa percentuale del tempo totale LCP inviato alla console.
Entrambe le visualizzazioni sono state create con il seguente codice:
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load duration',
'Element render delay',
];
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
const navEntry = performance.getEntriesByType('navigation')[0];
const lcpResEntry = performance
.getEntriesByType('resource')
.filter((e) => e.name === lcpEntry.url)[0];
// Ignore LCP entries that aren't images to reduce DevTools noise.
// Comment this line out if you want to include text entries.
if (!lcpEntry.url) return;
// Compute the start and end times of each LCP sub-part.
// WARNING! If your LCP resource is loaded cross-origin, make sure to add
// the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
const ttfb = navEntry.responseStart;
const lcpRequestStart = Math.max(
ttfb,
// Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
);
const lcpResponseEnd = Math.max(
lcpRequestStart,
lcpResEntry ? lcpResEntry.responseEnd : 0
);
const lcpRenderTime = Math.max(
lcpResponseEnd,
// Use LCP startTime (the final LCP time) because there are sometimes
// slight differences between loadTime/renderTime and startTime
// due to rounding precision.
lcpEntry ? lcpEntry.startTime : 0
);
// Clear previous measures before making new ones.
// Note: due to a bug, this doesn't work in Chrome DevTools.
LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));
// Create measures for each LCP sub-part for easier
// visualization in the Chrome DevTools Performance panel.
const lcpSubPartMeasures = [
performance.measure(LCP_SUB_PARTS[0], {
start: 0,
end: ttfb,
}),
performance.measure(LCP_SUB_PARTS[1], {
start: ttfb,
end: lcpRequestStart,
}),
performance.measure(LCP_SUB_PARTS[2], {
start: lcpRequestStart,
end: lcpResponseEnd,
}),
performance.measure(LCP_SUB_PARTS[3], {
start: lcpResponseEnd,
end: lcpRenderTime,
}),
];
// Log helpful debug information to the console.
console.log('LCP value: ', lcpRenderTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
console.table(
lcpSubPartMeasures.map((measure) => ({
'LCP sub-part': measure.name,
'Time (ms)': measure.duration,
'% of LCP': `${
Math.round((1000 * measure.duration) / lcpRenderTime) / 10
}%`,
}))
);
}).observe({type: 'largest-contentful-paint', buffered: true});
Puoi utilizzare questo codice così com'è per il debug locale o modificarlo per inviare questi dati a un fornitore di servizi di analisi in modo da comprendere meglio la suddivisione dell'LCP nelle tue pagine per gli utenti reali.
Riepilogo
L'LCP è complessa e la sua tempistica può essere influenzata da una serie di fattori. Tuttavia, se consideri che l'ottimizzazione dell'LCP riguarda principalmente il carico della risorsa LCP, le cose possono essere semplificate notevolmente.
A grandi linee, l'ottimizzazione dell'LCP può essere riassunta in quattro passaggi:
- Assicurati che la risorsa LCP inizi a caricarsi il prima possibile.
- Assicurati che l'elemento LCP possa essere visualizzato non appena la risorsa termina il caricamento.
- Riduci il più possibile il tempo di caricamento della risorsa LCP senza sacrificare la qualità.
- Carica il documento HTML iniziale il più rapidamente possibile.
Se riesci a seguire questi passaggi nelle tue pagine, puoi stare certo di offrire ai tuoi utenti un'esperienza di caricamento ottimale e dovresti vedere questo risultato nei tuoi punteggi LCP reali.