LCP - Largest Contentful Paint | Tra i Core web Vitals il più importante?

Non riesco a vedere alcun contenuto utile! Perché ci vuole così tanto tempo per caricare? 😖

Un fattore che contribuisce a un’esperienza utente scadente è il tempo impiegato da un utente per visualizzare qualsiasi contenuto visualizzato sullo schermo.

Il First Contentful Paint (FCP) misura il tempo necessario per il rendering del contenuto DOM iniziale, ma non rileva quanto tempo è stato necessario per il rendering del contenuto più grande (di solito anche il più significativo) sulla pagina.

Largest Contentful Paint (LCP) è una metrica dei Core Web Vitals e misura quando l’elemento di contenuto più grande nella finestra diventa visibile. Può essere utilizzato per determinare quando il contenuto principale della pagina ha terminato il rendering sullo schermo.

Le cause più comuni di un cattivo LCP sono:

Bassi tempi di risposta del server
Render-blocking JavaScript e CSS
Basse risorce del tempo di caricamento
Client-side rendering

Tempi di risposta del server lenti

Più tempo impiega un browser per ricevere contenuto dal server, più tempo impiega per eseguire il rendering di qualsiasi cosa sullo schermo. Un tempo di risposta del server più rapido migliora direttamente ogni singola metrica di caricamento della pagina, incluso il parametro LCP.

Prima di ogni altra cosa, migliora come e dove il tuo server gestisce i tuoi contenuti. Usa Time to First Byte (TTFB) per misurare i tempi di risposta del tuo server. Puoi migliorare il tuo TTFB in diversi modi:

Ottimizza il tuo server
Indirizza gli utenti a una rete CDN vicina
Risorse della cache
Servi le pagine HTML prima nella cache
Stabilisci in anticipo connessioni di terze parti
Usa scambi firmati (SXG)

Ottimizza il tuo server

Stai eseguendo query dispendiose che richiedono molto tempo al tuo server per essere completate?

O ci sono altre operazioni complesse in corso lato server che ritardano il processo di rendering del contenuto della pagina? Analizzare e migliorare l’efficienza del tuo codice lato server migliorerà direttamente il tempo necessario al browser per ricevere i dati.

Invece di servire immediatamente una pagina statica su richiesta del browser, molti framework Web lato server devono creare la pagina Web in modo dinamico.

In altre parole, invece d’inviare semplicemente un file HTML completo che già pronto quando il browser lo richiede, i framework eseguono una logica per costruire la pagina. Ciò potrebbe essere dovuto a risultati in sospeso da una query del database o anche a componenti che devono essere generati all’interno di un MarkUP da un Framework UI (come React).

Molti framework Web eseguiti sul server dispongono d’indicazioni sulle prestazioni che puoi utilizzare per accelerare questo processo.

Leggi anche : Come Google calcola i core web vitals

Attenzione: se quando carichi il tuo sito web vedi un Errore 500 o un errore 502, questo significa che il tuo server ha un problema. Per risolvere questo problema leggi Errore 500 o Errore 502

Dai un’occhiata all’articolo “Riparare un server sovraccarico” per ulteriori suggerimenti.

Indirizza gli utenti a una rete CDN vicina

Una Content Delivery Network (CDN) è una rete di server distribuiti in molte posizioni diverse. Se il contenuto della tua pagina Web è ospitato su un unico server, il tuo sito Web verrà caricato più lentamente per gli utenti geograficamente più lontani perché le loro richieste del browser devono letteralmente viaggiare in tutto il mondo. Prendi in seria considerazione l’utilizzo di una rete CDN per assicurarti che i tuoi utenti non debbano mai attendere richieste di rete a server lontani. Ma attenzione a questo lato. Se sei un novizio è fondamentale avere vicino una figura tecnica come un esperto WordPress e un esperto di reti e di velocizzazione di un sito web per non mandare in fumo i tuoi sforzi.

Risorse cache

Se il tuo codice HTML è statico e non deve essere modificato a ogni richiesta, la memorizzazione nella cache di questi contenuti può impedirne la ricreazione (che richiede diverso tempo). Archiviando una copia dell’HTML generato, su disco, la memorizzazione nella cache lato server può ridurre il TTFB (Time to first byte) e ridurre al minimo l’utilizzo delle risorse.

A seconda della tua toolchain, ci sono molti modi diversi per applicare la memorizzazione nella cache del server:

Configura proxy inverso (Varnish, nginx) per servire il contenuto memorizzato nella cache o fungere da server cache quando installato davanti a un server delle applicazioni
Configura e gestisci il comportamento della cache del tuo provider cloud (Firebase, AWS, Azure).
Utilizza una rete CDN che fornisce server perimetrali in modo che i tuoi contenuti vengano memorizzati nella cache e archiviati più vicino ai tuoi utenti

Servi le pagine HTML prima della cache

Una volta installato, un Service Worker viene eseguito in background del browser e può intercettare le richieste dal server. Questo livello di controllo della cache a livello di programmazione consente di memorizzare nella cache parte o tutto il contenuto della pagina HTML e di aggiornare la cache solo quando il contenuto è stato modificato.

Il grafico seguente mostra come le distribuzioni LCP sono state ridotte su un sito utilizzando questo modello:

Il grafico mostra la distribuzione per LCP da un singolo sito negli ultimi 28 giorni, segmentata per stato del lavoratore del servizio. Nota quanti più caricamenti di pagina hanno un valore LCP più veloce dopo l’introduzione della prima pagina HTML nella cache nel lavoratore del servizio (parte blu del grafico).

Per saperne di più sulle tecniche per servire pagine HTML complete o parziali prima della cache, dai un’occhiata a Smaller HTML Payloads with Service Workers

Stabilisci connessioni di terze parti in anticipo #

Anche le richieste del server a origini di terze parti possono influenzare soprattutto sull’LCP, se sono necessarie per visualizzare i contenuti sulla pagina. Usa rel=”preconnect” per informare il browser che la tua pagina intende stabilire una connessione il prima possibile.

<link rel="preconnect" href="https://esempio.com" />

Puoi anche utilizzare dns-prefetch per risolvere più rapidamente le ricerche DNS.

Sebbene entrambi i suggerimenti funzionino in modo diverso, considera l’utilizzo di dns-prefetch come fallback per i browser che non supportano la preconnessione.

<head>
…
<link rel="preconnect" href="https://example.com" />
<link rel="dns-prefetch" href="https://example.com" />
</head>

Usa gli scambi firmati (SXG)

Gli scambi firmati (SXG) sono un meccanismo di consegna che consente esperienze utente più rapide fornendo contenuti in un formato facilmente memorizzabile nella cache. In particolare, Google search memorizza nella cache e talvolta precarica gli SXG.

Per i siti che ricevono gran parte del loro traffico dalla Ricerca Google, gli SXG possono essere uno strumento importante per migliorare l’LCP. Per ulteriori informazioni, vedi Signed exchange.

Leggi la Guida Search Console per Principianti

JavaScript e CSS che bloccano il rendering

Prima che un browser possa eseguire il rendering di qualsiasi contenuto, deve analizzare il markup HTML in un albero DOM. Il parser HTML andrà in pausa se incontra fogli di stile esterni (<link rel=”stylesheet”>) o tag JavaScript sincroni (<script src=”main.js”>).

Script e fogli di stile sono entrambi risorse di blocco del rendering che ritardano FCP(First Contentful Paint) e, di conseguenza, LCP. Rinvia qualsiasi JavaScript e CSS non critico per velocizzare il caricamento del contenuto principale della tua pagina web.

Riduci il tempo di blocco CSS

Assicurati che solo la quantità minima di CSS necessaria stia bloccando il rendering sul tuo sito con quanto segue:

- Minimizza CSS

- Ritarda il caricamento di CSS non critico

- CSS critico in linea

Minimizza CSS

Per una maggiore leggibilità, i file CSS possono contenere caratteri come spaziatura, rientro o commenti.

Questi caratteri non sono tutti necessari per il browser e la riduzione a icona di questi file assicurerà che vengano rimossi.

In definitiva, la riduzione della quantità di CSS di blocco migliorerà sempre il tempo necessario per eseguire il rendering completo del contenuto principale della pagina (LCP).

Se utilizzi un bundler di moduli o uno strumento di compilazione, includi un plug-in appropriato per ridurre al minimo i file CSS su ogni build:

Per il webpack: optimization-css-assets-webpack-plugin
Per Gulp: gulp-clean-css
Per Rollup: rollup-plugin-css-porter

Per maggiori dettagli Guida alla Minificazione Css

Leggi anche: Il confronto dei migliori WP Plugin Cache

Rinvia CSS non critico

Utilizza la scheda Copertura in Chrome DevTools per trovare eventuali CSS inutilizzati sulla tua pagina web.

Per ottimizzare:

- Rimuovi completamente qualsiasi CSS inutilizzato o spostalo su un altro foglio di stile se utilizzato su una pagina separata del tuo sito.

- Per qualsiasi CSS non necessario per il rendering iniziale, usa loadCSS per caricare i file in modo asincrono, sfruttando rel=”preload” e onload.

<link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">

Per maggiori dettagli, fai riferimento alla guida Defer non-critical CSS.

CSS critico in linea

Metti Inline qualsiasi CSS del percorso critico utilizzato per il contenuto above-the-fold includendolo direttamente in <head>.

CSS critico integrato

L’integrazione di stili importanti elimina la necessità di effettuare una richiesta di andata e ritorno per recuperare CSS critici. Il differimento del resto riduce al minimo il tempo di blocco CSS.

Se non puoi aggiungere manualmente stili in linea al tuo sito, usa una libreria per automatizzare il processo. Qualche esempio:

Critical, CriticalCSS e Penthouse sono tutti pacchetti che estraggono e incorporano CSS above-the-fold
Critters è un plugin webpack che integra CSS critici e carica il resto via lazyload.

Per ulteriori informazioni vedi la guida Estrarre Css critico.

Riduci il tempo di blocco di JavaScript

Scarica e offri agli utenti la quantità minima di JavaScript necessario. La riduzione della quantità di JavaScript bloccante si traduce in un rendering del sito più veloce e, di conseguenza, in un LCP migliore.

Questo può essere ottenuto ottimizzando i tuoi script in diversi modi:

Minimizza e comprimi i file JavaScript
Rinvia JavaScript inutilizzato
Riduci al minimo i polyfill inutilizzati
La guida Optimize First Input Delay copre tutte le tecniche necessarie per ridurre il tempo di blocco di JavaScript in modo un po’ più dettagliato.

Tempi di caricamento delle risorse lenti

Sebbene un aumento del tempo di blocco CSS o JavaScript comporterà direttamente prestazioni peggiori, anche il tempo necessario per caricare molti altri tipi di risorse può influire sui tempi di disegno. I tipi di elementi che influenzano l’LCP sono:

- <img> elementi immagine

- <image> elementi all’interno di un elemento <svg>

- Elementi <video> (l’immagine del poster viene utilizzata per misurare l’LCP)

Un elemento con un’immagine di sfondo caricata tramite la funzione url() (al contrario di un gradiente CSS)
Elementi a livello di blocco contenenti nodi di testo o altri elementi di testo a livello di linea.
Il tempo necessario per caricare questi elementi se renderizzati above-the-fold avrà un effetto diretto su LCP. Esistono alcuni modi per garantire che questi file vengano caricati il più velocemente possibile:

- Ottimizza e comprimi le immagini

- Precarica risorse importanti

- Comprimi file di testo

- Fornisci risorse diverse in base alla connessione di rete (servizio adattivo)

- Archivia le risorse nella cache utilizzando un addetto ai servizi

Ottimizza e comprimi le immagini

Per molti siti, le immagini sono l’elemento più grande visualizzato al termine del caricamento della pagina. Hero image, grandi caroselli o immagini di banner sono tutti esempi comuni di questo elemento (LCP).

Migliorare il tempo necessario per caricare e renderizzare questi tipi di immagini accelererà direttamente il largest contentful paint (LCP) per farlo:

- Considera non utilizzare un’immagine come prima parte di pagina. Se non è rilevante per il contenuto, rimuovila.

- Comprimi le immagini (ad esempio con Image min)

- Converti le immagini in formati più recenti (JPEG 2000, JPEG XR o WebP)

- Usa immagini responsive

- Prendi in considerazione l’utilizzo di un’immagine CDN

Dai un’occhiata a Ottimizza le tue immagini guide e risorse che spiegano tutte queste tecniche in dettaglio.

Precarica risorse importanti

A volte, le risorse importanti dichiarate o utilizzate in un determinato file CSS o JavaScript possono essere recuperate più tardi di quanto vorresti, ad esempio un font nascosto in uno dei tanti file CSS di un’applicazione.

Se sai che una determinata risorsa dovrebbe avere la priorità, usa <link rel=”preload”> per recuperarla prima. Molti tipi di risorse possono essere precaricati, ma dovresti prima concentrarti sul precaricamento di risorse critiche, come caratteri, immagini o video above-the-fold e CSS o JavaScript del percorso critico.

<link rel="preload" as="script" href="script.js" />
<link rel="preload" as="style" href="style.css" />
<link rel="preload" as="image" href="img.png" />
<link rel="preload" as="video" href="vid.webm" type="video/webm" />
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin />

A partire da Chrome 73, il precaricamento può essere utilizzato insieme alle immagini responsive per combinare entrambi i modelli per un caricamento delle immagini molto più veloce.

<link
rel="preload"
as="image"
href="wolf.jpg"
imagesrcset="wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w"
imagesizes="50vw"
/>

Comprimi file di testo

Gli algoritmi di compressione, come Gzip e Brotli, possono ridurre significativamente le dimensioni dei file di testo (HTML, CSS, JavaScript) mentre vengono trasferiti tra il server e il browser. Gzip è effettivamente supportato in tutti i browser e Brotli, che fornisce risultati di compressione ancora migliori, può essere utilizzato in quasi tutti i browser più recenti.

La compressione delle tue risorse ridurrà al minimo le loro dimensioni di consegna, migliorando i tempi di caricamento e di conseguenza LCP.

Innanzitutto, controlla se il tuo server comprime già i file automaticamente. La maggior parte delle piattaforme di hosting, CDN e server proxy inverso codificano le risorse con la compressione per impostazione predefinita o consentono di configurarle facilmente.

A proposito se ancora non hai le idee chiare su cosa sia un Hosting leggi la nostra pagina “Cos’è un Hosting“.

Se devi modificare il tuo server per comprimere i file, considera l’utilizzo di Brotli invece di gzip poiché può fornire rapporti di compressione migliori.
Dopo aver scelto un algoritmo di compressione da utilizzare, comprimi le risorse in anticipo durante il processo di compilazione anziché al volo come richiesto dal browser. Ciò riduce al minimo l’overhead del server e previene i ritardi quando vengono effettuate le richieste, soprattutto quando si utilizzano rapporti di compressione elevati.

Serving adattivo

Quando si caricano risorse che costituiscono il contenuto principale di una pagina, può essere efficace recuperare condizionalmente risorse diverse a seconda del dispositivo dell’utente o delle condizioni della rete. Questo può essere fatto utilizzando le API Network Information, Device Memory e HardwareConcurrency.

Se disponi di risorse di grandi dimensioni che sono fondamentali per il rendering iniziale, puoi utilizzare diverse varianti della stessa risorsa a seconda della connessione o del dispositivo dell’utente. Ad esempio, puoi visualizzare un’immagine anziché un video per qualsiasi velocità di connessione inferiore a 4G:

if (navigator.connection && navigator.connection.efficaceType) {
if (navigator.connection.efficaceType === '4g') {
// Carica video
} altro {
// Carica immagine
}
}

Un elenco di proprietà utili che puoi utilizzare:

- navigator.connection.effectType: tipo di connessione efficace

- navigator.connection.saveData: salva dati abilitato/disabilitato

- navigator.hardwareConcurrency: conteggio dei core della CPU

- navigator.deviceMemory: Memoria del dispositivo

Per ulteriori informazioni, fare riferimento a Servizio adattivo basato sulla qualità della rete.

Memorizza nella cache le risorse utilizzando un Service Worker

I service worker possono essere usati per molte attività utili, inclusa la gestione di risposte HTML più piccole, come menzionato in precedenza in questo articolo. Possono anche essere usati per memorizzare nella cache qualsiasi risorsa statica che può essere servita al browser invece che dalla rete su richieste ripetute.

La memorizzazione nella cache di risorse critiche utilizzando un addetto ai servizi può ridurre notevolmente i tempi di caricamento, soprattutto per gli utenti che ricaricano la pagina Web con una connessione più debole (o addirittura accedono offline). Le librerie come Workbox possono semplificare il processo di aggiornamento delle risorse memorizzate nella cache rispetto alla scrittura di un addetto ai servizi personalizzato per gestirlo tu stesso.

Dai un’occhiata a Affidabilità della rete per saperne di più sugli addetti all’assistenza e su Workbox.

Rendering lato client

Molti siti utilizzano la logica JavaScript lato client per visualizzare le pagine direttamente nel browser. Framework e librerie, come React, Angular e Vue, hanno semplificato la creazione di applicazioni a pagina singola che gestiscono diversi aspetti di una pagina Web interamente sul client anziché sul server.

Se stai creando un sito che è per lo più renderizzato sul client, dovresti stare attento all’effetto che può avere su LCP se viene utilizzato un pacchetto JavaScript di grandi dimensioni. Se non sono state messe in atto le ottimizzazioni per prevenirlo, gli utenti potrebbero non vedere o interagire con alcun contenuto della pagina fino a quando tutto il JavaScript critico non ha terminato il download e l’esecuzione.

Quando crei un sito con rendering lato client, considera le seguenti ottimizzazioni:

- Riduci al minimo JavaScript critico

- Usa il rendering lato server

- Usa il pre-rendering

Riduci al minimo JavaScript critico

Se i contenuti del tuo sito diventano visibili, o con cui è possibile interagire, solo dopo aver scaricato una certa quantità di JavaScript: diventa ancora più importante ridurre le dimensioni del tuo bundle il più possibile. Questo può essere fatto da:

- Minimizzare JavaScript

- Rinviare JavaScript inutilizzato

- Ridurre al minimo i polyfill inutilizzati

Torna alla sezione Riduci il tempo di blocco di JavaScript per saperne di più su queste ottimizzazioni.

Usa il rendering lato server

Ridurre al minimo la quantità di JavaScript dovrebbe sempre essere la prima cosa su cui concentrarsi per i siti che sono per lo più visualizzati dal client. Tuttavia, dovresti anche considerare di combinare un’esperienza di rendering del server per migliorare il più possibile LCP.

Questo concetto funziona utilizzando il server per eseguire il rendering dell’applicazione in HTML, dove il client “idrata” tutto il JavaScript e i dati richiesti sullo stesso contenuto DOM. Ciò può migliorare LCP assicurando che il contenuto principale della pagina venga prima visualizzato sul server anziché solo sul client, ma ci sono alcuni inconvenienti:

Il mantenimento della stessa applicazione con rendering JavaScript sul server e sul client può aumentare la complessità.
L’esecuzione di JavaScript per eseguire il rendering di un file HTML sul server aumenterà sempre i tempi di risposta del server (TTFB) rispetto alla sola pubblicazione di pagine statiche dal server.
Una pagina sottoposta a rendering dal server può sembrare con cui è possibile interagire, ma non può rispondere a nessun input dell’utente finché tutto il JavaScript lato client non è stato eseguito. In breve, può peggiorare Time to Interactive (TTI).

Usa il pre-rendering

Il pre-rendering è una tecnica separata che è meno complessa del rendering lato server e fornisce anche un modo per migliorare l’LCP nell’applicazione. Un browser headless, che è un browser senza interfaccia utente, viene utilizzato per generare file HTML statici di ogni percorso durante la fase di compilazione. Questi file possono quindi essere spediti insieme ai bundle JavaScript necessari per l’applicazione.

Con il pre-rendering, TTI ha ancora un impatto negativo, ma i tempi di risposta del server non sono influenzati come con una soluzione di rendering lato server che esegue il rendering dinamico di ogni pagina solo dopo che è stata richiesta.

Per un’analisi più approfondita delle diverse architetture di rendering dei server, dai un’occhiata a Rendering sul web.

Strumenti di sviluppo

Sono disponibili numerosi strumenti per la misurazione ed eseguire il debug di LCP:

Lighthouse 6.0 include il supporto per la misurazione dell’LCP in un ambiente di laboratorio.

La sezione del Pannello Prestazioni in Chrome DevTools dedicata ai “tempi” include un indicatore LCP e mostra quale elemento è associato all’LCP quando passi con il mouse sul campo Nodo correlato.

LCP in Chrome DevTools
Il rapporto sull’esperienza utente di Chrome fornisce valori LCP reali aggregati a livello di origine

Fonte: https://web.dev/optimize-lcp/

In questo post, hai imparato come migliorare Largest Contentful Paint in WordPress utilizzando varie tecniche. A volte, può essere opprimente comprendere tutto il gergo tecnico e applicarlo perfettamente.

Fortunatamente, un provider hosting veloce come il Nostro Nitro Cloud e un plug-in di grandi prestazioni come WP Rocket possono aiutarti a ottenere un buon punteggio LCP fin da subito.

Se vuoi ricevere una nostra consulenza immediata per la velocità del tuo sito, Contattaci Subito!

LCP – Largest Contentful Paint | Tra i Core web Vitals il più importante?