Una guida passo passo su come suddividere la metrica LCP e identificare le aree chiave da migliorare.
La metrica Largest Contentful Paint (LCP) è una delle tre metriche di Segnali web essenziali e rappresenta la velocità di caricamento dei contenuti principali di una pagina web. In particolare, la metrica LCP misura il tempo che intercorre tra l'avvio del caricamento della pagina da parte dell'utente e il rendering dell'immagine o del blocco di testo più grande all'interno dell'area visibile.
Per offrire una buona esperienza utente, i siti devono avere una LCP pari o inferiore a 2,5 secondi per almeno il 75% delle visite alle pagine.
Diversi fattori possono influire sulla velocità di caricamento e rendering di una pagina web da parte del browser e i ritardi tra una pagina e l'altra possono avere un impatto significativo sulla metrica LCP.
È raro che una correzione rapida di una singola parte di una pagina comporti un miglioramento significativo della metrica LCP. Per migliorare il valore LCP, devi esaminare l'intero processo di caricamento e assicurarti che ogni passaggio sia ottimizzato.
Comprendere la metrica LCP
Prima di ottimizzare la metrica LCP, gli sviluppatori devono cercare di capire se hanno un problema LCP e l'entità del problema.
La LCP può essere misurata utilizzando diversi strumenti e non tutti misurano l'LCP nello stesso modo. Per comprendere la metrica LCP degli utenti reali, dobbiamo guardare a ciò che stanno vivendo gli utenti reali piuttosto che a come mostra uno strumento di laboratorio come Lighthouse o un test locale. Questi strumenti basati su lab possono fornire una grande quantità di informazioni utili per aiutarti a migliorare l'LCP. Tuttavia, tieni presente che i test di laboratorio da soli potrebbero non essere del tutto rappresentativi dell'esperienza utente.
I dati LCP basati su utenti reali possono essere ottenuti dagli strumenti di monitoraggio degli utenti reali (RUM) installati su un sito oppure utilizzando il Report sull'esperienza utente di Chrome (CrUX), che raccoglie dati anonimi di utenti reali di Chrome per milioni di siti web.
Utilizzo dei dati LCP CrUX di PageSpeed Insights
PageSpeed Insights fornisce l'accesso ai dati di CrUX nella sezione superiore chiamata Scopri cosa stanno scoprendo i tuoi utenti reali. Dati più dettagliati basati sui lab sono disponibili nella sezione in basso denominata Diagnostica i problemi di prestazioni. Se i dati CrUX sono disponibili per il tuo sito web, concentrati sempre sui dati utente reali.
PageSpeed Insights mostra fino a quattro diversi dati CrUX:
- Dati mobili per Questo URL
- Dati computer per Questo URL
- Dati mobili per l'intera Origine
- Dati desktop per l'intera origine
Puoi attivare/disattivare i 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 relativi all'origine, PageSpeed Insights mostra sempre i dati di origine.
Il valore LCP relativo all'intera origine può essere molto diverso dall'LCP di una singola pagina, a seconda di come viene caricato nella pagina in questione rispetto alle altre pagine dell'origine. Inoltre, può dipendere dal modo in cui i visitatori navigano in queste pagine. Le home page tendono a essere visitate da nuovi utenti, pertanto spesso vengono caricate in modalità "fredda", senza contenuti memorizzati nella cache e, quindi, sono spesso le pagine più lente di un sito web.
Osservare le quattro diverse categorie di dati di CrUX può aiutarti a capire se un problema di LCP è specifico di questa pagina o un problema più generale a livello di sito. Analogamente, può mostrare quali tipi di dispositivi presentano problemi di LCP.
Utilizzo di metriche supplementari CrUX di PageSpeed Insights
Coloro che vogliono ottimizzare l'LCP dovrebbero anche utilizzare i tempi First Contentful Paint (FCP) e Time to First Byte (TTFB), che sono buone metriche di diagnostica in grado di fornire informazioni preziose sulla metrica LCP.
Per TTFB si intende il tempo in cui il visitatore inizia a navigare su una pagina (ad esempio facendo clic su un link) fino a quando non vengono ricevuti i primi byte del documento HTML. Un TTFB elevato può rendere il raggiungimento di un LCP di 2, 5 secondi impegnativo o addirittura impossibile.
Un TTFB elevato può essere dovuto a più reindirizzamenti del server, ai visitatori che si trovano lontano dal server del sito più vicino, a visitatori in condizioni di rete scadenti o all'impossibilità di utilizzare i contenuti memorizzati nella cache a causa dei parametri di ricerca.
Una volta avviato il rendering di una pagina, potrebbe essere visualizzato un colore iniziale (ad esempio il colore di sfondo) seguito da alcuni contenuti (ad esempio l'intestazione del sito). L'aspetto dei contenuti iniziali viene misurato dalla metrica FCP. Il delta tra il valore FCP e altre metriche può essere molto significativo.
Un grande delta tra TTFB e FCP potrebbe indicare che il browser deve scaricare molti asset che bloccano la visualizzazione. Può anche indicare che la visualizzazione di contenuti significativi deve richiedere molto lavoro, un classico segnale di un sito che fa molto affidamento sul rendering lato client.
Un grande delta tra FCP e LCP indica che la risorsa LCP non è immediatamente disponibile per la priorità da parte del browser (ad esempio, testo o immagini gestiti tramite JavaScript anziché disponibili nel codice HTML iniziale) o che il browser sta completando un'altra operazione prima di poter visualizzare i contenuti LCP.
Utilizzo dei dati Lighthouse di PageSpeed Insights
La sezione Lighthouse di PageSpeed Insights offre alcune indicazioni per migliorare l'LCP, ma prima è necessario verificare se questo valore è ampiamente d'accordo con i dati utente reali forniti da CrUX. Se Lighthouse e CrUX non sono d'accordo, è probabile che CrUX fornisca un quadro più accurato della tua esperienza utente. Prima di agire, assicurati che i dati CrUX siano relativi alla tua pagina, non all'origine completa.
Se sia Lighthouse che CrUX mostrano valori di LCP che richiedono miglioramenti, la sezione Lighthouse può fornire indicazioni preziose su come migliorare il valore LCP. Utilizza il filtro LCP per mostrare solo i controlli pertinenti alla metrica LCP nel seguente modo:
Oltre alle opportunità di miglioramento, ci sono informazioni di diagnostica che potrebbero fornire ulteriori informazioni per aiutare a diagnosticare il problema. La diagnostica elemento Largest Contentful Paint mostra un'analisi utile dei vari tempi che compongono la LCP:
Parleremo di queste sottoparti più avanti.
Suddivisione LCP
L'ottimizzazione per LCP può essere un'attività più complessa quando PageSpeed Insights non ti dà una risposta su come migliorare questa metrica. Nel caso di attività complesse, in genere è meglio suddividerle in attività più piccole e più gestibili da affrontare separatamente.
Questa sezione presenta una metodologia su come suddividere l'LCP nelle sue sottoparti più critiche e quindi presenta consigli e best practice specifici su come ottimizzare ciascuna parte.
La maggior parte dei caricamenti delle pagine in genere include una serie di richieste di rete, ma al fine di identificare opportunità per migliorare l'LCP, ti consigliamo di iniziare esaminando solo due richieste:
- Il documento HTML iniziale
- Risorsa LCP (se applicabile)
Mentre altre richieste nella pagina possono influire su LCP, queste due richieste, in particolare l'inizio e la fine della risorsa LCP, rivelano se la pagina è ottimizzata o meno per LCP.
Per identificare la risorsa LCP, puoi utilizzare gli strumenti per sviluppatori (come PageSpeed Insights di cui sopra, Chrome DevTools o WebPageTest) per determinare l'elemento LCP. Da qui puoi associare l'URL (di nuovo, se applicabile) caricato dall'elemento in una struttura a cascata della rete di tutte le risorse caricate dalla pagina.
Ad esempio, la seguente visualizzazione mostra queste risorse in un diagramma a cascata di rete a partire da un tipico caricamento pagina, in cui l'elemento LCP richiede una richiesta di immagine per il rendering.
Per una pagina ben ottimizzata, vuoi che la richiesta di risorsa LCP inizi a caricarsi il prima possibile e vuoi che l'elemento LCP venga visualizzato il più rapidamente possibile al termine del caricamento della risorsa LCP. Per visualizzare più facilmente se una determinata pagina segue questo principio, puoi suddividere il tempo LCP totale nelle seguenti sottoparti:
- Tempo per il primo 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 di caricamento delle risorse
- Il tempo che intercorre tra TTFB e l'inizio del caricamento della risorsa LCP da parte del browser. Se l'elemento LCP non richiede un carico di risorse per il rendering (ad esempio, se l'elemento è un nodo di testo visualizzato con un carattere di sistema), il valore è 0.
- Durata di caricamento delle risorse
- Il tempo necessario per caricare la risorsa LCP. Se l'elemento LCP non richiede un carico di risorse per il rendering, il tempo è pari a 0.
- Ritardo di rendering dell'elemento
- Il tempo che intercorre tra il termine del caricamento della risorsa LCP e la visualizzazione completa dell'elemento LCP.
L'LCP di ogni pagina è costituito da queste quattro sottocategorie. Non esistono differenze o sovrapposizioni tra loro e sommano il tempo LCP completo.
Per ogni pagina è possibile suddividere il valore LCP in queste quattro sottoparti. Non vi sono sovrapposizioni o spazi tra loro. Insieme, vengono sommati al tempo LCP completo.
Durante l'ottimizzazione dell'LCP, è utile provare a ottimizzare queste sottoparti singolarmente. Ma è anche importante tenere presente che è necessario ottimizzarli tutti. In alcuni casi, un'ottimizzazione applicata a una parte non migliorerà il valore di LCP, ma sposterà semplicemente il tempo risparmiato su un'altra parte.
Ad esempio, nella precedente struttura a cascata di rete, se riducivi le dimensioni del file dell'immagine comprimendola di più o passando a un formato più ottimale (come AVIF o WebP), la durata del caricamento delle risorse verrebbe ridotta, ma in realtà il LCP non verrebbe migliorato, perché il tempo passerebbe solo alla sottoparte ritardo di rendering dell'elemento:
Il motivo è che in questa pagina l'elemento LCP è nascosto fino al termine del caricamento del codice JavaScript e poi visualizzato tutto in una volta.
Questo esempio aiuta a illustrare il punto in cui è necessario ottimizzare tutte queste sottoparti per ottenere i migliori risultati LCP.
Tempi delle sottoparte ottimali
Per ottimizzare ogni sottoparte di LCP, è importante capire qual è la ripartizione ideale di queste sottoparti in una pagina ben ottimizzata.
Delle quattro sottoparti, due contengono la parola "ritardo" nei nomi. Questo è un indizio che vorresti ottenere questo tempo il più vicino possibile a zero. Le altre due parti riguardano le richieste di rete, che per loro stessa natura richiedono tempo.
Tieni presente che queste suddivisioni temporali sono linee guida, non regole rigide. Se i tempi LCP sulle tue pagine sono costantemente entro 2,5 secondi, non importa quali sono le proporzioni relative. Tuttavia, se trascorri molto tempo superfluo in una delle due parti, sarà molto difficile raggiungere costantemente l'obiettivo di 2,5 secondi.
Un buon modo per pensare alla suddivisione del tempo LCP è:
- La vasta maggior parte del tempo LCP dovrebbe essere dedicata al caricamento del documento HTML e dell'origine LCP.
- Qualsiasi momento prima dell'LCP in cui una di queste due risorse non viene caricata è un'opportunità di miglioramento.
Come ottimizzare ogni parte
Ora che hai compreso in che modo ogni intervallo LCP deve essere suddiviso in una pagina ben ottimizzata, puoi iniziare a ottimizzare le tue pagine.
Nelle quattro sezioni successive troverai consigli e best practice su come ottimizzare ogni parte. Sono presentati in ordine, a partire dalle ottimizzazioni che hanno più probabilità di avere l'impatto maggiore.
1. Elimina il ritardo nel caricamento delle risorse
L'obiettivo di questo passaggio è garantire che il caricamento della risorsa LCP inizi il prima possibile. Anche se in teoria il caricamento di una risorsa può iniziare subito dopo il TTFB, in pratica c'è sempre un ritardo prima che i browser inizino effettivamente a caricare le risorse.
Come buona regola generale, la risorsa LCP deve iniziare a caricarsi contemporaneamente alla prima risorsa caricata dalla pagina. Oppure, in altre parole, se la risorsa LCP inizia a essere caricata dopo la prima risorsa, c'è la possibilità di migliorare.
In generale, la velocità di caricamento di una risorsa LCP dipende da due fattori:
- Quando la risorsa viene rilevata.
- La priorità assegnata alla risorsa.
Ottimizza quando la risorsa viene rilevata
Per garantire che il caricamento della risorsa LCP venga avviato il prima possibile, è fondamentale che la risorsa sia rilevabile nella risposta iniziale del documento HTML 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 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 questo viene caricato utilizzando
<link rel="preload">nel markup HTML (o tramite un'intestazioneLink).
Di seguito sono riportati alcuni esempi in cui non è possibile rilevare la risorsa LCP dalla scansione della risposta del documento HTML:
- L'elemento LCP è un elemento
<img>che viene aggiunto dinamicamente alla pagina tramite JavaScript. - L'elemento LCP viene caricato lentamente con una libreria JavaScript che nasconde i relativi attributi
srcosrcset(spesso comedata-srcodata-srcset). - L'elemento LCP richiede un'immagine di sfondo CSS.
In ognuno di questi casi, prima che possa rilevare la risorsa LCP e iniziare a caricarla, il browser deve eseguire lo script o applicare il foglio di stile (che di solito comporta l'attesa del completamento delle richieste di rete). Non è mai una soluzione ottimale.
Per eliminare inutili ritardi nel caricamento delle risorse, la risorsa LCP dovrebbe essere rilevabile dall'origine HTML. Nei casi in cui viene fatto riferimento alla risorsa 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, il caricamento potrebbe ancora non iniziare già dalla prima risorsa. Questo può accadere se le euristiche di priorità dello scanner di precaricamento del browser non riconoscono 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" sul tuo elemento <img>. Se utilizzi il caricamento lento, la risorsa non verrà caricata finché il layout non avrà confermato che l'immagine è nell'area visibile e quindi potrebbe iniziare il caricamento più tardi del previsto.
Anche senza il caricamento lento, le immagini non vengono inizialmente caricate con la massima priorità dai browser poiché non sono risorse che bloccano la visualizzazione. Puoi suggerire al browser quali sono le risorse più importanti utilizzando l'attributo fetchpriority per le risorse che potrebbero trarre vantaggio da una priorità più elevata:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Ti consigliamo di impostare fetchpriority="high" su un elemento <img> se pensi che sia probabilmente l'elemento LCP della tua pagina. Tuttavia, impostare una priorità elevata su più di una o due immagini rende inutile l'impostazione della priorità per ridurre l'LCP.
Puoi anche ridurre 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 slide del carosello che non sono visibili all'avvio:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
La riduzione della priorità di alcune risorse può fornire più larghezza di banda a quelle che ne hanno bisogno di più, ma fai attenzione. Controlla sempre la priorità delle risorse in DevTools e testa le modifiche con strumenti di lab e sul campo.
Dopo aver ottimizzato la priorità delle risorse LCP e il tempo di rilevamento, 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 dell'elemento
L'obiettivo di questo passaggio è garantire che l'elemento LCP possa essere visualizzato immediatamente al termine del caricamento della risorsa, indipendentemente da quando succede.
Il motivo principale per cui l'elemento LCP non è in grado di eseguire il rendering subito dopo il completamento del caricamento della risorsa è se il rendering è bloccato per qualche altro motivo:
- Il rendering dell'intera pagina è bloccato a causa di fogli di stile o script sincroni in
<head>ancora in fase di caricamento. - La risorsa LCP ha terminato il caricamento, ma l'elemento LCP non è ancora stato aggiunto al DOM (attende il caricamento di codice JavaScript).
- L'elemento è nascosto da un altro codice, ad esempio una libreria di test A/B che sta ancora determinando l'esperimento a cui dovrebbe partecipare l'utente.
- Il thread principale è bloccato a causa di attività lunghe e il lavoro di rendering deve attendere il completamento di queste attività lunghe.
Le seguenti sezioni spiegano come risolvere le cause più comuni di ritardo di rendering non necessario degli elementi.
Riduci o incorpora i fogli di stile che bloccano la visualizzazione
I fogli di stile caricati dal markup HTML bloccheranno il rendering di tutti i contenuti che li seguono, il che è positivo, dato che in genere non si vuole visualizzare HTML senza stile. Tuttavia, se il foglio di stile è talmente grande da richiedere molto più tempo per caricarsi rispetto alla risorsa LCP, questo impedirà il rendering dell'elemento LCP, anche al termine del caricamento della risorsa, come mostrato in questo esempio:
Per risolvere il problema, le opzioni a tua disposizione sono:
- incorpora 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 le dimensioni del foglio di stile sono ridotte, in quanto i contenuti incorporati nell'HTML non possono trarre vantaggio dalla memorizzazione nella cache nei caricamenti pagina successivi. Se un foglio di stile è talmente grande che il caricamento impiega più tempo della risorsa LCP, è improbabile che sia una buona candidata per l'incorporamento.
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 siano inferiori a quelle 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 il CSS inutilizzato: utilizza Chrome DevTools per trovare le regole CSS che non vengono utilizzate e che potrebbero essere rimosse (o differite).
- Rimanda CSS non fondamentale: suddividi il foglio di stile in stili necessari per il caricamento iniziale della pagina e successivamente in stili che possono essere caricati lentamente.
- Minimizza e comprimi CSS: per gli stili fondamentali, assicurati di ridurre il più possibile le dimensioni di trasferimento.
JavaScript che blocca la visualizzazione rinvia o in linea
Non è quasi mai necessario aggiungere script sincroni (script senza gli attributi async o defer) ai <head> delle pagine e questo avrà quasi sempre un impatto negativo sul rendimento.
Nei casi in cui il codice JavaScript deve essere eseguito il prima possibile nel caricamento della pagina, è preferibile integrarlo in modo che il rendering non subisca ritardi in attesa di un'altra richiesta di rete. Tuttavia, come per i fogli di stile, dovresti utilizzare gli script incorporati 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>
Utilizza 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 dell'LCP, esistono due vantaggi principali della metrica SSR:
- Le risorse immagine saranno rilevabili dalla sorgente HTML (come spiegato nel passaggio 1 in precedenza).
- I contenuti della pagina non richiedono il completamento di ulteriori richieste JavaScript prima di poter essere visualizzati.
Il principale svantaggio di SSR è che richiede un tempo di elaborazione aggiuntivo del server, che può rallentare il TTFB. In genere vale la pena di apportare questo compromesso perché i tempi di elaborazione del server sono sotto il tuo controllo, mentre le funzionalità di rete e dei dispositivi degli utenti non lo sono.
Un'opzione simile a SSR è chiamata generazione statica del sito (SSG) o prerendering. Si tratta del processo di generazione delle pagine HTML in un passaggio di creazione anziché on demand. Se il prerendering è possibile con la tua architettura, in genere rappresenta una scelta migliore per le prestazioni.
Suddividi le attività lunghe
Anche se hai seguito i consigli di cui sopra e il tuo codice JavaScript non blocca la visualizzazione né è responsabile del rendering degli elementi, può comunque ritardare LCP.
Il motivo più comune di questo problema è quando 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 scaricata completamente, potrebbe essere necessario attendere il termine dell'esecuzione di uno script non correlato prima di poter eseguire il rendering.
Tutti i browser attualmente visualizzano le immagini nel thread principale, il che significa che qualsiasi elemento che blocchi il thread principale può causare anche un ritardo di rendering dell'elemento inutile.
3. Riduci la durata del caricamento delle risorse
L'obiettivo di questo passaggio è ridurre il tempo impiegato per trasferire i byte della risorsa sulla rete al dispositivo dell'utente. In generale, puoi farlo in tre modi:
- Riduci le dimensioni della risorsa.
- Riduci la distanza che la risorsa deve percorrere.
- Ridurre i conflitti per la larghezza di banda della rete.
- Eliminare del tutto il tempo trascorso in rete.
Riduci le dimensioni della risorsa
La risorsa LCP di una pagina (se presente) sarà un'immagine o un carattere web. Le seguenti guide illustrano in dettaglio come ridurre le dimensioni di entrambi:
- Pubblicare le dimensioni ottimali delle immagini
- Utilizzare formati delle immagini moderni
- Comprimi le immagini
- Ridurre le dimensioni dei caratteri web
Riduci la distanza percorsa dalla risorsa
Oltre a ridurre le dimensioni di una risorsa, puoi anche ridurre i tempi di caricamento posizionando i server il più vicino possibile agli utenti dal punto di vista geografico. Il modo migliore per farlo è utilizzare una rete CDN (Content Delivery Network).
Le CDN di immagine in particolare sono particolarmente utili perché non solo riducono la distanza che la risorsa deve percorrere, ma in genere ne riducono anche le dimensioni, implementando automaticamente tutti i suggerimenti di riduzione delle dimensioni descritti in precedenza.
Ridurre i conflitti per la larghezza di banda di 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 contesa di rete.
Se hai assegnato un valore fetchpriority elevato alla tua risorsa LCP e hai iniziato a caricarla il prima possibile, il browser farà del suo meglio per evitare che risorse a priorità inferiore competano con essa. Tuttavia, se stai caricando molte risorse con un valore elevato di fetchpriority o se stai semplicemente caricando molte risorse in generale, la velocità di caricamento della risorsa LCP potrebbe risentirne.
Eliminare del tutto il tempo trascorso in rete
Il modo migliore per ridurre la durata del caricamento delle risorse è eliminare completamente la rete dal processo. Se gestisci le tue risorse con un criterio di controllo efficiente della cache, i visitatori che le richiedono una seconda volta le riceveranno dalla cache, portando la durata del caricamento delle risorse sostanzialmente a zero.
Se la risorsa LCP è un carattere web, oltre a ridurre le dimensioni dei caratteri web, devi valutare anche se devi bloccare il rendering durante il caricamento delle risorse dei caratteri web. Se imposti un valore font-display diverso da auto o block, il testo sarà sempre visibile durante il caricamento e la metrica LCP non verrà bloccata su un'ulteriore richiesta di rete.
Infine, se la tua risorsa LCP è di piccole dimensioni, può essere opportuno incorporarle sotto forma di URL di dati, eliminando così anche la richiesta di rete aggiuntiva. Tuttavia, l'utilizzo di URL di dati prevede un'avvertenza, perché le risorse non possono essere memorizzate nella cache e, in alcuni casi, può comportare ritardi di visualizzazione più lunghi a causa del costo di decodifica aggiuntivo.
4. Riduci il time to first byte
L'obiettivo 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 consegna il primo byte di contenuto, quindi qualsiasi cosa tu faccia per velocizzare il tuo TTFB migliorerà anche ogni altra metrica relativa al carico.
Una causa comune della lentezza del TTFB in un sito altrimenti veloce è costituita dai visitatori che arrivano tramite più reindirizzamenti, ad esempio da pubblicità o link abbreviati. Riduci sempre al minimo il numero di reindirizzamenti che un visitatore deve attendere.
Un'altra causa comune è l'impossibilità di utilizzare i contenuti memorizzati nella cache da un server perimetrale CDN e tutte le richieste devono essere indirizzate completamente al server di origine. Ciò può verificarsi se i visitatori utilizzano parametri URL univoci per l'analisi, anche se non generano pagine diverse.
Per indicazioni specifiche sull'ottimizzazione della TTFB, consulta la guida sull'ottimizzazione della TTFB.
Monitora la suddivisione LCP in JavaScript
Le informazioni sulla tempistica per tutte le sottoparti LCP discusse in precedenza sono disponibili in JavaScript tramite una combinazione delle seguenti API per le prestazioni:
Il vantaggio del calcolo di questi valori di tempo in JavaScript è che puoi inviarli a un provider di analisi o registrarli negli strumenti per sviluppatori per facilitare il debug e l'ottimizzazione.
Ad esempio, nel seguente screenshot viene utilizzato il metodo performance.measure() dell'API User Timing per aggiungere barre al canale Timings nel riquadro Prestazioni di Chrome DevTools.
Le visualizzazioni nella traccia Tempi sono particolarmente utili se visualizzate insieme alle tracce Rete e Thread principale, perché puoi vedere a colpo d'occhio cos'altro sta accadendo nella pagina in questi intervalli di tempo.
Oltre a visualizzare le sottoparti LCP nel monitoraggio della sincronizzazione, puoi anche utilizzare JavaScript per calcolare la percentuale di ciascuna sottoparte del 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 percentuale del tempo LCP totale nella console.
Entrambe queste 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 oppure modificarlo per inviare questi dati a un provider di analisi in modo da poter capire meglio la suddivisione dell'LCP sulle tue pagine per gli utenti reali.
Monitora le analisi LCP utilizzando l'estensione Web Vitals
L'estensione Web Vitals registra il tempo LCP, l'elemento LCP e queste quattro sottoparti nella console, per consentirti di vedere facilmente questa suddivisione.
Riepilogo
La metrica LCP è complessa e le tempistiche possono essere influenzate da una serie di fattori. Tuttavia, se ritieni che l'ottimizzazione dell'LCP riguardi principalmente l'ottimizzazione del carico della risorsa LCP, può semplificare notevolmente le cose.
A livello generale, l'ottimizzazione dell'LCP può essere riassunta in quattro passaggi:
- Assicurati che il caricamento della risorsa LCP inizi il prima possibile.
- Assicurati che l'elemento LCP possa essere visualizzato al termine del caricamento della risorsa.
- Riduci il più possibile il tempo di caricamento della risorsa LCP senza sacrificare la qualità.
- Pubblica il documento HTML iniziale il più rapidamente possibile.
Se sei in grado di seguire questi passaggi sulle tue pagine, dovresti avere la certezza di offrire agli utenti un'esperienza di caricamento ottimale e questo risultato sarà considerato dai punteggi LCP reali.