Largest Contentful Paint (LCP) è una delle tre metriche Core Web Vitals e rappresenta la velocità con cui viene caricato il contenuto principale di una pagina web. Nello specifico, LCP misura il tempo da quando l’utente avvia il caricamento della pagina fino a quando l’immagine o il blocco di testo più grande viene visualizzato all’interno del viewport.

Per fornire una buona esperienza utente, i siti dovrebbero sforzarsi di avere un LCP di 2,5 secondi o meno per almeno il 75% delle visite alle pagine.

Esistono numerosi fattori che possono influire sulla velocità con cui il browser è in grado di caricare e visualizzare una pagina Web e i ritardi su ognuno di essi possono avere un impatto significativo su LCP.

È raro che una correzione rapida a una singola parte di una pagina si traduca in un miglioramento significativo di LCP. Per migliorare LCP devi esaminare l’intero processo di caricamento e assicurarti che ogni fase lungo il percorso sia ottimizzata.

Comprensione della metrica LCP #

Prima di ottimizzare LCP, gli sviluppatori dovrebbero cercare di capire se hanno persino un problema LCP e l’entità di tale problema.

LCP può essere misurato in una serie di strumenti e non tutti misurano LCP allo stesso modo. Per comprendere l’LCP degli utenti reali, dovremmo guardare a ciò che gli utenti reali stanno vivendo, piuttosto che a ciò che mostra uno strumento basato su laboratorio come Lighthouse o test locali. Questi strumenti di laboratorio possono fornire una grande quantità di informazioni per spiegare e aiutarti a migliorare LCP, ma tieni presente che i test di laboratorio da soli potrebbero non essere del tutto rappresentativi di ciò che sperimentano i tuoi utenti effettivi.

I dati LCP basati su utenti reali possono essere rilevati dagli strumenti Real User Monitoring (RUM) installati su un sito o tramite Chrome User Experience Report (CrUX) che raccolgono dati anonimi da utenti reali di Chrome per milioni di siti web.

Utilizzo dei dati LCP CrUX di PageSpeed ​​Insights #

PageSpeed ​​Insights fornisce l’accesso ai dati CrUX nella sezione superiore etichettata Scopri cosa stanno vivendo i tuoi utenti reali . Dati di laboratorio più dettagliati sono disponibili nella sezione inferiore denominata Diagnostica problemi di prestazioni . Se i dati CrUX sono disponibili per il tuo sito web, concentrati sempre prima sui dati degli utenti reali.

Laddove CrUX non fornisce dati (ad esempio, una pagina con traffico insufficiente per ottenere dati a livello di pagina), CrUX dovrebbe essere integrato con i dati RUM raccolti utilizzando le API JavaScript in esecuzione sulla pagina web. Questo può anche fornire molti più dati di quelli che CrUX può esporre come set di dati pubblici. Più avanti in questa guida spiegheremo come raccogliere questi dati utilizzando JavaScript.

PageSpeed ​​Insights mostra fino a quattro diversi dati CrUX:

• Dati mobili per questo URL
• Dati desktop per questo URL
• Dati mobili per l’intera origine
• Dati desktop per l’intera origine

Questi possono essere attivati ​​nei controlli in alto e in alto a destra di questa sezione. Tieni presente che se un URL non dispone di dati sufficienti per essere mostrato a livello di URL, ma dispone di dati per l’origine, PageSpeed ​​Insights lo mostrerà automaticamente.

L’LCP per l’intera origine può essere molto diverso dall’LCP di una singola pagina a seconda di come l’LCP viene caricato su quella pagina rispetto ad altre pagine su quell’origine. Può anche essere influenzato dal modo in cui i visitatori navigano su queste pagine. Le home page tendono ad essere visitate da nuovi utenti e quindi spesso possono essere caricate “a freddo”, senza alcun contenuto memorizzato nella cache e quindi sono spesso le pagine più lente di un sito web.

Osservare le quattro diverse categorie di dati CrUX può aiutarti a capire se un problema LCP è specifico di questa pagina o un problema più generale a livello di sito. Allo stesso modo, può mostrare quali tipi di dispositivi presentano problemi di LCP.

Utilizzo delle metriche supplementari CrUX di PageSpeed ​​Insights #

Coloro che cercano di ottimizzare LCP dovrebbero anche utilizzare i tempi First Contentful Paint (FCP) e Time to First Byte (TTFB) , che sono buone metriche diagnostiche che possono fornire preziose informazioni su LCP.

TTFB è il momento in cui il visitatore inizia a navigare verso una pagina (ad esempio, facendo clic su un collegamento), fino a quando non 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 situati lontano dal server del sito più vicino, visitatori in cattive condizioni di rete o impossibilità di utilizzare il contenuto memorizzato nella cache a causa dei parametri di query.

Una volta avviato il rendering di una pagina, potrebbe essere presente un colore iniziale (ad esempio, il colore di sfondo), seguito dalla visualizzazione di alcuni contenuti (ad esempio, l’intestazione del sito). L’aspetto del contenuto iniziale è misurato da FCP. Il delta tra FCP e altre metriche può essere molto indicativo.

Un grande delta tra TTFB e FCP potrebbe indicare che il browser deve scaricare molte risorse che bloccano il rendering. Può anche essere un segno che deve completare molto lavoro per rendere qualsiasi contenuto significativo, un classico segno 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à del browser (ad esempio, testo o immagini gestiti da JavaScript anziché essere disponibili nell’HTML iniziale) o che il browser sta completando altro lavoro prima di poter visualizzare il contenuto LCP.

Utilizzo dei dati di PageSpeed ​​Insights Lighthouse #

La sezione Lighthouse di PageSpeed ​​Insights offre alcune indicazioni per migliorare l’LCP, ma prima dovresti verificare se l’LCP fornito è sostanzialmente in linea con i dati degli utenti reali forniti da CrUX.

Se Lighthouse non mostra alcun problema LCP, ma i dati CrUX lo sono, allora qualsiasi suggerimento di Lighthouse potrebbe non essere pertinente. È vero anche il contrario: se Lighthouse mostra un tempo LCP davvero scarso, ma i dati CrUX mostrano che i tuoi utenti hanno per lo più un buon LCP, allora potresti considerare la priorità di ottimizzare ulteriormente LCP, o se il tempo è meglio speso per altri miglioramenti delle prestazioni. Assicurati anche di controllare che i dati CrUX siano per questa pagina e non per l’origine completa come descritto sopra.

Se entrambe le fonti di dati mostrano un LCP che dovrebbe essere migliorato, la sezione Lighthouse può fornire preziose indicazioni su come migliorare LCP. Utilizza il filtro LCP per mostrare solo gli audit rilevanti per LCP:

Oltre alle opportunità di miglioramento, sono disponibili informazioni diagnostiche che possono fornire ulteriori informazioni per aiutare a diagnosticare il problema. La diagnostica dell’elemento Paint più grande e ricco di contenuti mostra un’utile suddivisione dei vari tempi che costituivano l’LCP:

Approfondiremo queste sotto-parti in seguito.

Ripartizione LCP #

L’ottimizzazione per LCP può essere un’attività più complessa quando PageSpeed ​​Insights non ti dà la risposta su come migliorare questa metrica. Con compiti complessi è generalmente meglio suddividerli in compiti più piccoli e più gestibili e affrontarli separatamente. Questa guida presenterà una metodologia su come suddividere LCP nelle sue sottoparti più critiche e quindi presenterà raccomandazioni specifiche e migliori pratiche su come ottimizzare ciascuna parte.Per una panoramica visiva del contesto presentato in questa sezione, consulta 

A Deep Dive into Optimizing LCP from Google I/O 2022:

La maggior parte dei caricamenti di pagina in genere include una serie di richieste di rete, ma allo scopo di identificare le opportunità per migliorare LCP, dovresti iniziare esaminandone solo due:

1. Il documento HTML iniziale
2. La risorsa LCP (se applicabile)

Mentre altre richieste sulla pagina possono influenzare LCP, queste due richieste, in particolare gli orari in cui la risorsa LCP inizia e finisce, rivelano se la tua pagina è ottimizzata o meno per LCP.

Per identificare la risorsa LCP, puoi utilizzare strumenti per sviluppatori (come PageSpeed ​​Insights discusso sopra, Chrome DevTools o WebPageTest ) per determinare l’ elemento LCP . Da lì, puoi abbinare l’URL (di nuovo, se applicabile) caricato dall’elemento su una cascata di rete di tutte le risorse caricate dalla pagina.

Ad esempio, la seguente visualizzazione mostra queste risorse evidenziate in un diagramma a cascata di rete da un tipico caricamento della pagina, in cui l’elemento LCP richiede una richiesta di immagine per il rendering.

Per una pagina ben ottimizzata, si desidera che la richiesta della risorsa LCP inizi a caricarsi il prima possibile e si desidera che l’elemento LCP venga visualizzato il più rapidamente possibile al termine del caricamento della risorsa LCP. Per aiutare a visualizzare se una determinata pagina segue o meno questo principio, puoi suddividere il tempo LCP totale nelle seguenti sottoparti:

Questa tabella spiega ciascuna di queste sottoparti LCP in modo più dettagliato:

Sottoparte LCP	Descrizione
Tempo al primo byte (TTFB)	Il tempo da quando l’utente avvia il caricamento della pagina fino a quando il browser riceve il primo byte della risposta del documento HTML. (Vedi il documento sulla metrica TTFB per maggiori dettagli.)
Ritardo nel caricamento delle risorse	Il delta tra TTFB e quando il browser inizia a caricare la risorsa LCP. *
Tempo di caricamento delle risorse	Il tempo necessario per caricare la risorsa LCP stessa. *
Ritardo di rendering dell’elemento	Il delta tra il momento in cui la risorsa LCP termina il caricamento e il rendering completo dell’elemento LCP.

Ogni singola pagina può avere il suo valore LCP suddiviso in queste quattro sottoparti. Non vi è alcuna sovrapposizione o divario tra di loro e collettivamente si sommano al tempo LCP completo.

Quando si ottimizza LCP, è utile cercare di ottimizzare singolarmente queste parti secondarie. Ma è anche importante tenere presente che è necessario ottimizzarli tutti. In alcuni casi, un’ottimizzazione applicata a una parte non migliorerà LCP, sposterà semplicemente il tempo risparmiato su un’altra parte.

Ad esempio, nella cascata di rete precedente, se riducevi la dimensione del file della nostra immagine comprimendola di più o passando a un formato più ottimale (come AVIF o WebP), ciò ridurrebbe il tempo di caricamento delle risorse, ma in realtà non lo farebbe migliorare LCP perché il tempo si sposterebbe semplicemente alla sottoparte del ritardo di rendering dell’elemento :

Il motivo per cui ciò accade è perché, in questa pagina, l’elemento LCP è nascosto fino a quando il codice JavaScript non termina il caricamento, quindi tutto viene rivelato in una volta.

Questo esempio aiuta a illustrare il punto che è necessario ottimizzare tutte queste parti secondarie per ottenere i migliori risultati LCP.

Tempi secondari ottimali #

Per ottimizzare ogni sottoparte di LCP, è importante capire qual è la suddivisione ideale di queste sottoparti in una pagina ben ottimizzata.

Delle quattro sottoparti, due hanno la parola “ritardo” nel nome. Questo è un indizio che vuoi ottenere questi tempi il più vicino possibile allo zero. Le altre due parti riguardano le richieste di rete, che per loro stessa natura richiedono tempo.

Sottoparte LCP	% di PCL
Tempo al primo byte (TTFB)	~40%
Ritardo nel caricamento delle risorse	<10%
Tempo di caricamento delle risorse	~40%
Ritardo di rendering dell’elemento	<10%
TOTALE	100%

Nota che queste suddivisioni temporali non sono regole rigide, sono linee guida. Se i tempi LCP sulle tue pagine sono costantemente entro 2,5 secondi, allora non importa quali siano le proporzioni relative. Ma se trascorri molto tempo non necessario in una delle porzioni di “ritardo”, sarà molto difficile raggiungere costantemente l’ obiettivo di 2,5 secondi .

Un buon modo per pensare alla suddivisione del tempo LCP è:

• La stragrande maggioranza del tempo LCP dovrebbe essere impiegata per caricare il documento HTML e il sorgente LCP.
• Qualsiasi momento prima di LCP in cui una di queste due risorse non viene caricata è un’opportunità per migliorare .

AvvertimentoDato l’ 

obiettivo di 2,5 secondi per LCP, si potrebbe essere tentati di convertire queste percentuali in numeri assoluti, ma non è consigliabile. Queste sottoparti sono significative solo l’una rispetto all’altra, quindi è meglio misurarle sempre in questo modo.

Come ottimizzare ogni parte #

Ora che hai compreso come ciascuno dei tempi secondari dell’LCP dovrebbe suddividersi su una pagina ben ottimizzata, puoi iniziare a ottimizzare le tue pagine.

Le quattro sezioni successive presenteranno raccomandazioni e best practice su come ottimizzare ciascuna parte. Sono presentati in ordine, a partire dalle ottimizzazioni che probabilmente avranno l’impatto maggiore.

1. Elimina il ritardo nel caricamento delle risorse #

L’obiettivo in questo passaggio è garantire che la risorsa LCP inizi a caricarsi il prima possibile. Mentre in teoria il primo caricamento di una risorsa è subito 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 tua risorsa LCP dovrebbe iniziare a caricarsi contemporaneamente alla prima risorsa caricata da quella pagina. Oppure, per dirla in un altro modo, se la risorsa LCP inizia a caricarsi più tardi della prima risorsa, allora c’è un’opportunità di miglioramento.

In generale, ci sono due fattori che influenzano la velocità di caricamento di una risorsa LCP:

• Quando la risorsa viene scoperta.
• Quale priorità viene assegnata alla risorsa.

Ottimizza quando la risorsa viene scoperta #

Per garantire che la tua risorsa LCP inizi a caricarsi 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 scansionando la risposta del documento HTML:

• L’elemento LCP è un <img>elemento e i suoi attributi srco srcsetsono presenti nel markup HTML iniziale.
• L’elemento LCP richiede un’immagine di sfondo CSS, ma quell’immagine è precaricata tramite <link rel="preload">nel markup HTML (o tramite un’intestazione Link).
• L’elemento LCP è un nodo di testo che richiede il rendering di un font Web e il font viene caricato tramite <link rel="preload">il markup HTML (o tramite Linkun’intestazione).

Di seguito sono riportati alcuni esempi in cui la risorsa LCP non può essere rilevata 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 pigramente con una libreria JavaScript che nasconde i suoi attributi srco srcset(spesso come data-srco data-srcset).
• L’elemento LCP richiede un’immagine di sfondo CSS.

In ciascuno di questi casi, il browser deve eseguire lo script o applicare il foglio di stile, il 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 inutili ritardi nel caricamento delle risorse, la tua risorsa LCP dovrebbe essere sempre rilevabile dall’origine HTML. Nei casi in cui si fa riferimento alla risorsa solo da un file CSS o JavaScript esterno, la risorsa LCP dovrebbe essere precaricata, con un’alta priorità di recupero (maggiori informazioni sulla priorità di recupero nella sezione successiva ); Per 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">

AvvertimentoSulla maggior parte delle pagine, è sufficiente garantire che la risorsa LCP inizi a caricarsi contemporaneamente alla prima risorsa, ma tieni presente che è possibile costruire una pagina in cui nessuna delle risorse viene scoperta in anticipo e tutte iniziano a caricarsi molto più tardi rispetto al TTFB. Quindi, sebbene il confronto con la prima risorsa sia un buon modo per identificare le opportunità di miglioramento, in alcuni casi potrebbe non essere sufficiente, quindi è comunque importante misurare questo tempo rispetto al TTFB e assicurarsi che rimanga piccolo.

Ottimizza la priorità assegnata alla risorsa #

Anche se la risorsa LCP è rilevabile dal markup HTML, potrebbe comunque non iniziare a caricarsi già dalla prima risorsa. Ciò 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 la tua immagine LCP tramite HTML se imposti loading="lazy"sul tuo <img>elemento. L’uso del caricamento lento significa che la risorsa non verrà caricata fino a quando il layout non confermerà che l’immagine è nel viewport e quindi potrebbe iniziare a caricarsi più tardi di quanto farebbe altrimenti.

AvvertimentoNon eseguire mai il lazy-load dell’immagine LCP, poiché ciò comporterà sempre un inutile ritardo nel caricamento delle risorse e avrà un impatto negativo su LCP.

Anche senza caricamento lento, le immagini non vengono inizialmente caricate con la massima priorità dai browser in quanto non sono risorse che bloccano il rendering. Puoi suggerire al browser quali risorse sono più importanti tramite l’ fetchpriorityattributo per le risorse che potrebbero beneficiare di una priorità più alta:

<img fetchpriority="high" src="/path/to/hero-image.webp">

È una buona idea impostare fetchpriority="high"un <img>elemento se ritieni che sia probabile che sia l’elemento LCP della tua pagina, ma limitalo a solo una o due immagini (basate sulle comuni dimensioni del viewport desktop e mobile), altrimenti il ​​segnale perde di significato. Puoi anche ridurre la priorità delle immagini che potrebbero essere all’inizio della risposta del documento, ma non sono visibili a causa dello stile, come le immagini nelle diapositive del carosello che non sono visibili all’avvio:

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

La riduzione della priorità di determinate risorse può consentire una maggiore larghezza di banda per le risorse che ne hanno più bisogno, ma fai attenzione. Controlla sempre la priorità delle risorse in DevTools e verifica le modifiche con strumenti di laboratorio e sul campo.

Dopo aver ottimizzato la priorità della risorsa LCP e il tempo di scoperta, la struttura a cascata della rete dovrebbe apparire così (con la risorsa LCP che inizia contemporaneamente alla prima risorsa):

ImportanteUn altro motivo per cui la tua risorsa LCP potrebbe non iniziare a caricarsi il prima possibile, anche quando è rilevabile dall’origine HTML, è se è ospitata su un’origine diversa, poiché queste richieste richiedono che il browser si connetta a quell’origine prima che la risorsa possa iniziare a caricarsi. Quando possibile, è una buona idea ospitare le risorse critiche sulla stessa origine della risorsa del documento HTML perché in tal caso tali risorse possono risparmiare tempo riutilizzando la connessione esistente (ne parleremo più avanti su questo punto).

2. Elimina il ritardo di rendering degli elementi #

L’obiettivo in questo passaggio è garantire che l’elemento LCP possa eseguire il rendering immediatamente dopo che la sua risorsa ha terminato il caricamento, indipendentemente da quando ciò accade.

Il motivo principale per cui l’elemento LCP non sarebbe in grado di eseguire il rendering immediatamente dopo che la sua risorsa ha terminato il caricamento è se il rendering è bloccato per qualche altro motivo:

• Il rendering dell’intera pagina è bloccato a causa di fogli di stile o script sincroni in fase di <head>caricamento.
• La risorsa LCP ha terminato il caricamento, ma l’elemento LCP non è stato ancora aggiunto al DOM (è in attesa del caricamento del codice JavaScript).
• L’elemento viene nascosto da qualche altro codice, come una libreria di test A/B che sta ancora determinando in quale esperimento dovrebbe trovarsi l’utente.
• Il thread principale è bloccato a causa di attività lunghe e il lavoro di rendering deve attendere il completamento di tali attività lunghe.

Le sezioni seguenti spiegano come affrontare le cause più comuni di un ritardo di rendering degli elementi non necessario.

Ridurre o incorporare i fogli di stile che bloccano il rendering #

I fogli di stile caricati dal markup HTML bloccheranno il rendering di tutto il contenuto che li segue, il che è positivo, poiché in genere non si desidera eseguire il rendering di HTML senza stile. Tuttavia, se il foglio di stile è così grande da richiedere molto più tempo per il caricamento rispetto alla risorsa LCP, allora impedirà il rendering dell’elemento LCP, anche dopo che la sua risorsa ha terminato il caricamento, come mostrato in questo esempio:

Per risolvere questo problema, le tue opzioni sono:

• incorporare il foglio di stile nell’HTML per evitare la richiesta di rete aggiuntiva; O,
• ridurre le dimensioni del foglio di stile.

In generale, l’incorporamento del foglio di stile è consigliato solo se il foglio di stile è piccolo poiché il contenuto incorporato nell’HTML non può beneficiare della memorizzazione nella cache nei successivi caricamenti della pagina. Se un foglio di stile è così grande da richiedere più tempo per essere caricato rispetto alla risorsa LCP, è improbabile che sia un buon candidato per l’incorporamento.

Nella maggior parte dei casi, il modo migliore per garantire che il foglio di stile non blocchi il rendering dell’elemento LCP è ridurne le dimensioni in modo che sia più piccolo della risorsa LCP. Ciò dovrebbe garantire che non sia un collo di bottiglia per la maggior parte delle visite.

Alcuni consigli per ridurre le dimensioni del foglio di stile sono:

• Rimuovi CSS inutilizzati : utilizza Chrome DevTools per trovare le regole CSS che non vengono utilizzate e che possono essere potenzialmente rimosse (o rinviate).
• Defer non-critical CSS : dividi il tuo foglio di stile in stili che sono richiesti per il caricamento iniziale della pagina e poi stili che possono essere caricati pigramente.
• Minimizza e comprimi CSS : per gli stili critici, assicurati di ridurre il più possibile le dimensioni di trasferimento .

Posticipa o JavaScript che blocca il rendering in linea #

Non è quasi mai necessario aggiungere script sincroni (script senza gli attributi asynco defer) alle <head>tue pagine, e farlo avrà quasi sempre un impatto negativo sulle prestazioni.

Nei casi in cui il codice JavaScript deve essere eseguito il prima possibile durante il caricamento della pagina, è meglio incorporarlo in modo che il rendering non venga ritardato in attesa di un’altra richiesta di rete. Come con i fogli di stile, tuttavia, dovresti incorporare gli script solo se sono molto piccoli.

Non

<head>
  <script src="/path/to/main.js"></script>
</head>

Fare

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

Usa 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, ci sono due vantaggi principali dell’SSR:

• Le tue risorse immagine saranno individuabili dalla sorgente HTML (come discusso nel passaggio 1 in precedenza).
• Il contenuto della tua pagina non richiederà ulteriori richieste JavaScript per terminare prima che possa essere visualizzato.

Il principale svantaggio di SSR è che richiede tempi di elaborazione del server aggiuntivi, che possono rallentare il tuo TTFB. Questo compromesso di solito ne vale la pena perché i tempi di elaborazione del server sono sotto il tuo controllo, mentre le capacità di rete e del dispositivo dei tuoi utenti non lo sono.

Un’opzione simile a SSR è chiamata generazione di siti statici (SSG) o prerendering . Questo è il processo di generazione delle tue pagine HTML in una fase di creazione piuttosto che su richiesta. Se il prerendering è possibile con la tua architettura, in genere è una scelta migliore per le prestazioni.

Interrompi compiti lunghi #

Anche se hai seguito i consigli di cui sopra e il tuo codice JavaScript non blocca il rendering né è responsabile del rendering dei tuoi elementi, può comunque ritardare LCP.

Il motivo più comune per cui ciò accade è quando le pagine caricano file JavaScript di grandi dimensioni, che devono essere analizzati ed eseguiti sul thread principale del browser. Ciò significa che, anche se la tua risorsa immagine è completamente scaricata, potrebbe comunque dover attendere fino al termine dell’esecuzione di uno script non correlato prima di poter eseguire il rendering.

Tutti i browser oggi eseguono il rendering delle immagini sul thread principale, il che significa che tutto ciò che blocca il thread principale può anche portare a un ritardo di rendering degli elementi non necessario .

3. Riduci il tempo di caricamento delle risorse #

L’obiettivo di questo passaggio è ridurre il tempo impiegato per trasferire i byte della risorsa attraverso la rete al dispositivo dell’utente. In generale, ci sono tre modi per farlo:

• Ridurre la dimensione della risorsa.
• Ridurre la distanza che la risorsa deve percorrere.
• Ridurre la contesa per la larghezza di banda della rete.
• Elimina completamente il tempo di rete.

Riduci la dimensione della risorsa #

La risorsa LCP di una pagina (se ne ha una) sarà un’immagine o un font web. Le seguenti guide entrano in dettaglio su come ridurre le dimensioni di entrambi:

• Servire la dimensione ottimale dell’immagine
• Usa formati immagine moderni
• Comprimi le immagini
• Riduci la dimensione del carattere web

Ridurre la distanza che la risorsa deve percorrere #

Oltre a ridurre le dimensioni di una risorsa, puoi anche ridurre i tempi di caricamento avvicinando geograficamente i tuoi server ai tuoi utenti. E il modo migliore per farlo è utilizzare una rete di distribuzione dei contenuti (CDN).

In effetti, i CDN di immagini in particolare sono un’ottima scelta perché non solo riducono la distanza che la risorsa deve percorrere, ma generalmente riducono anche le dimensioni della risorsa, implementando automaticamente tutti i consigli di riduzione delle dimensioni di prima per te.

ImportanteSebbene i CDN di immagini siano un ottimo modo per ridurre i tempi di caricamento delle risorse, l’utilizzo di un dominio di terze parti per ospitare le tue immagini comporta un costo di connessione aggiuntivo. Mentre la preconnessione all’origine può mitigare parte di questo costo, l’opzione migliore è quella di pubblicare immagini dalla stessa origine del documento HTML. Molti CDN ti consentono di inoltrare le richieste dalla tua origine alla loro, che è un’ottima opzione da esaminare se disponibile.

Riduci la contesa per la larghezza di banda della rete #

Anche se hai ridotto le dimensioni della tua risorsa e la distanza che deve percorrere, il caricamento di una risorsa può richiedere molto tempo se stai caricando molte altre risorse contemporaneamente. Questo problema è noto come conflitto di rete .

Se hai dato alla tua risorsa LCP un valore altofetchpriority 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 stai caricando molte risorse con alto fetchpriorityo se stai solo caricando molte risorse in generale, potrebbe influire sulla velocità di caricamento della risorsa LCP.

Elimina completamente il tempo di rete #

Il modo migliore per ridurre i tempi di caricamento delle risorse è eliminare completamente la rete dal processo. Se servi le tue risorse con un efficiente criterio di controllo della cache , i visitatori che richiedono tali risorse una seconda volta le riceveranno dalla cache, portando il tempo di caricamento delle risorse praticamente a zero!

E se la tua risorsa LCP è un font web, oltre a ridurre la dimensione del font web , dovresti anche considerare se è necessario bloccare il rendering sul caricamento della risorsa del font web. Se imposti un font-displayvalore diverso da autoo block, il testo sarà sempre visibile durante il caricamento e LCP non verrà bloccato su una richiesta di rete aggiuntiva.

Infine, se la tua risorsa LCP è piccola, potrebbe avere senso incorporare le risorse come URL di dati , che eliminerà anche la richiesta di rete aggiuntiva. Tuttavia, l’utilizzo degli URL di dati comporta delle avvertenze perché le risorse non possono essere memorizzate nella cache e in alcuni casi possono causare ritardi di rendering più lunghi a causa del costo di decodifica aggiuntivo .

4. Riduci il tempo al primo byte #

L’obiettivo di questo passaggio è fornire l’HTML iniziale il più rapidamente possibile. Questo passaggio è elencato per ultimo perché spesso è quello su cui gli sviluppatori hanno meno controllo. Tuttavia, è anche uno dei passaggi più importanti perché influisce direttamente su ogni passaggio successivo. Nulla può accadere sul frontend fino a quando il backend non consegna quel primo byte di contenuto, quindi qualsiasi cosa tu possa fare per accelerare il tuo TTFB migliorerà anche ogni altra metrica di carico.

Una causa comune di un TTFB lento per un sito altrimenti veloce è che i visitatori passano attraverso diversi reindirizzamenti prima di arrivare finalmente all’URL finale. Questo può accadere quando hai visitatori da annunci pubblicitari o tramite accorciatori di URL. Cerca sempre di ridurre al minimo il numero di reindirizzamenti che un visitatore deve attendere.

Un’altra causa comune è quando il contenuto memorizzato nella cache non può essere utilizzato da un server perimetrale CDN e tutte le richieste devono essere indirizzate fino al server di origine. Ciò può accadere se i parametri URL univoci vengono utilizzati dai visitatori per l’analisi, anche se non si traducono in pagine diverse.

Per una guida specifica su questo argomento, consulta Ottimizza TTFB .

Monitora la ripartizione LCP in JavaScript #

Le informazioni sulla tempistica per tutte le parti secondarie LCP discusse sopra sono disponibili in JavaScript tramite una combinazione delle seguenti API delle prestazioni:

• La più grande API Contentful Paint
• API dei tempi di navigazione
• API di temporizzazione delle risorse

Il vantaggio di calcolare questi valori di temporizzazione in JavaScript è che ti consente di inviarli a un provider di analisi o di registrarli nei tuoi strumenti di sviluppo per aiutarti con il debug e l’ottimizzazione.

Ad esempio, lo screenshot seguente utilizza il performance.measure()metodo dell’API User Timing per aggiungere barre alla traccia Timings nel pannello Performance di Chrome DevTools.

Le visualizzazioni nella traccia dei tempi sono particolarmente utili se guardate insieme alle tracce Network e Main thread, perché puoi vedere a colpo d’occhio cos’altro sta accadendo sulla pagina durante questi periodi di tempo.

Oltre a visualizzare le sottoparti LCP nella traccia dei tempi, puoi anche utilizzare JavaScript per calcolare la percentuale di ciascuna sottoparte rispetto al tempo LCP totale. Con queste informazioni, puoi determinare se le tue pagine soddisfano le suddivisioni percentuali consigliate descritte in precedenza.

Questa schermata mostra un esempio che registra il tempo totale di ogni sottoparte LCP, nonché la sua percentuale del tempo LCP totale alla console.

Entrambe queste visualizzazioni sono state create con il seguente codice:

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load time',
  '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 (which is the final LCP time) as 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 does not 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 analisi in modo da ottenere una migliore comprensione di quale sia la ripartizione di LCP sulle tue pagine per gli utenti reali.

Il codice precedente funziona per le navigazioni standard, ma è necessario prestare particolare attenzione alle pagine con prerendering , che dovrebbero essere misurate dall’ora di inizio dell’attivazione ma che sono state tenute fuori da questo codice per semplicità.

La libreria web-vitals include questa suddivisione nella build di attribuzione e include queste considerazioni.

Per coloro che desiderano implementare la propria soluzione, il codice per questo è open source ed è simile a quello sopra ma con lofic extra per l’avvio dell’attivazione.

Monitora la ripartizione LCP tramite l’estensione Web Vitals #

L’ estensione Web Vitals registrerà l’ora LCP, l’elemento LCP e queste quattro parti secondarie nella registrazione della console , per consentirti di visualizzare facilmente questa suddivisione.

Sommario n.

LCP è complesso e la sua tempistica può essere influenzata da una serie di fattori. Ma se consideri che l’ottimizzazione di LCP riguarda principalmente l’ottimizzazione del carico della risorsa LCP, può semplificare notevolmente le cose.

Ad alto livello, l’ottimizzazione dell’LCP può essere riassunta in quattro fasi:

1. Assicurarsi che la risorsa LCP inizi a caricarsi il prima possibile.
2. Assicurati che l’elemento LCP possa eseguire il rendering non appena la sua risorsa termina il caricamento.
3. Riduci il più possibile il tempo di caricamento della risorsa LCP senza sacrificare la qualità.
4. Consegna il documento HTML iniziale il più velocemente possibile.

Se sei in grado di seguire questi passaggi sulle tue pagine, dovresti sentirti sicuro di offrire un’esperienza di caricamento ottimale ai tuoi utenti e dovresti vederla riflessa nei tuoi punteggi LCP nel mondo reale.

Vuoi dare un’occhiata prima? Quindi guarda il nostro video e scopri come migliorare Largest Contentful Paint con WP Rocket in pochi clic !