Ottimizza la Resource Load Duration dell'LCP

Questa guida fa parte della sezione Largest Contentful Paint (LCP) del nostro centro risorse sui Core Web Vitals. La Resource Load Duration è la terza di quattro fasi sequenziali dell'LCP e misura il tempo necessario per scaricare la risorsa LCP tramite la rete. Mentre il Resource Load Delay spesso rappresenta una quota maggiore del tempo dell'LCP, ottimizzare la durata del download rimane essenziale per ottenere un buon punteggio LCP.

Ottimizza la Resource Load Duration dell'LCP

Il Largest Contentful Paint (LCP) è una delle tre metriche di performance dei Core Web Vitals che misurano l'esperienza utente online. L'LCP acquisisce il tempo necessario affinché l'elemento contentful più grande (un'immagine, un video o un blocco di testo) diventi visibile nel viewport. La Resource Load Duration è una sotto-parte dell'LCP che indica quanto tempo viene impiegato per recuperare la risorsa di rete per l'elemento LCP. Esaminiamo a fondo l'aspetto della Resource Load Duration dell'LCP e analizziamo il suo impatto e le strategie di ottimizzazione.

Cos'è la Resource Load Duration nell'LCP?

La Resource Load Duration, spesso chiamata Load Duration, si riferisce al tempo necessario al browser per scaricare la risorsa di rete (ad esempio, un'immagine) che diventerà alla fine l'elemento LCP. Per immagini e video, questa durata va da quando inizia il download dell'immagine a quando il browser completa il download. Per gli elementi LCP basati su testo, la Load Duration è in genere pari a zero.

La Resource Load Duration viene misurata dal momento in cui il browser inizia a scaricare la risorsa LCP fino al termine del download. Questa misurazione è importante perché influisce direttamente sulla rapidità con cui gli utenti possono vedere e interagire con il contenuto principale di una pagina web. La Resource Load Duration può essere influenzata da diversi fattori, tra cui:

• Dimensione del File: I file più grandi richiedono tempi di download più lunghi.
• Velocità di Rete: Le connessioni più lente estendono naturalmente la Load Duration.
• Reattività del Server: I ritardi nella risposta del server rallentano il recupero delle risorse.
• Download Simultanei: Le risorse scaricate contemporaneamente competono per la larghezza di banda, il che può aumentare i tempi di caricamento.

Come Rilevare la Resource Load Duration

Ci sono due modi efficaci per identificare e misurare la Resource Load Duration:

Ispezione di Rete in Chrome DevTools: Usa la scorciatoia Ctrl + Maiusc + I per aprire i Developer Tools di Chrome, quindi seleziona la scheda "Network" (Rete) e ricarica la pagina. Cerca l'elemento LCP nelle richieste di rete (se vuoi conoscere l'elemento LCP, prova il Core Web Visualizer). L'ispettore di rete ti mostrerà quanto tempo è stato necessario per scaricare la risorsa.

Suggerimento Pro: Abilita le righe di richiesta grandi per vedere dettagli aggiuntivi come la latenza dell'LCP, la dimensione trasferita e la dimensione effettiva.

Sfruttare i Dati del Real User Monitoring (RUM):

Gli strumenti RUM spesso registrano i dati di attribuzione dell'LCP. I dati di attribuzione per il Largest Contentful Paint contengono informazioni sulla Resource Load Duration. Questi dati consentono visualizzazioni delle tendenze della Load Duration nel tempo o per pagina, fornendo una visione chiara dei tempi di caricamento in tutto il sito. Analizzando questi pattern, è possibile identificare gli elementi che potrebbero rallentare i tempi di caricamento e scoprire opportunità mirate per prestazioni più veloci e fluide.

Come Migliorare la Load Duration dell'LCP

I problemi di Resource Load Duration si verificano quando le risorse sono troppo grandi o fornite su percorsi di rete non ottimali. Due approcci principali affrontano questo problema: ridurre la dimensione dei dati o ottimizzare la consegna dei dati. Ecco tecniche e pattern efficaci per migliorare la Resource Load Duration dell'LCP:

1. Ottimizza la Dimensione dei File

Ottimizzare la dimensione dei file riduce il numero di byte da inviare sulla rete. Meno dati di solito significa meno tempo di download. Per una guida completa all'ottimizzazione delle immagini, consulta il nostro articolo su come ottimizzare le immagini.

Usa Formati Immagine Moderni

AVIF e WebP sono all'avanguardia nella compressione. AVIF, in particolare, offre ampie capacità di compressione, riducendo spesso le dimensioni dei file fino al 50% rispetto a WebP, rendendolo ideale per foto complesse senza sacrificare la qualità. WebP, tuttavia, mantiene una forte compatibilità con una gamma più ampia di browser ed è particolarmente efficace per immagini più semplici.

Scegliere la Giusta Impostazione di Qualità

I formati immagine moderni come WebP e AVIF consentono una significativa riduzione della qualità prima che il degrado visivo diventi evidente. Come regola generale, un'impostazione di qualità tra 75 e 85 per WebP, e tra 60 e 75 per AVIF, produrrà immagini visivamente indistinguibili dall'originale a normali distanze di visualizzazione, ottenendo al contempo notevoli risparmi sulle dimensioni dei file. Testa sempre con le tue immagini specifiche, poiché la qualità ottimale dipende dal tipo di contenuto (fotografie vs illustrazioni vs immagini ricche di testo).

Automatizzare la Compressione delle Immagini con Sharp

Per l'ottimizzazione delle immagini in fase di build, la libreria sharp è uno degli strumenti più veloci e ampiamente utilizzati nell'ecosistema Node.js. Il seguente esempio mostra come convertire e comprimere un'immagine sia in formato WebP che AVIF con impostazioni di qualità ottimizzate:

const sharp = require('sharp');

// Convert to WebP with optimized quality
await sharp('input.jpg')
  .resize(1200)  // Resize to maximum needed width
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Convert to AVIF with optimized quality
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Generate multiple sizes for responsive images
const widths = [400, 800, 1200];
for (const width of widths) {
  await sharp('input.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}w.webp`);
}

Questo approccio genera tutte le varianti necessarie per un elemento <picture> responsive con supporto per formati moderni. Per i siti WordPress, plugin come ShortPixel o Imagify gestiscono questa conversione automaticamente durante il caricamento.

Immagini Responsive

L'elemento <picture> e l'attributo srcset consentono immagini su misura in base alle dimensioni dello schermo, permettendo versioni di immagini più piccole per mobile e versioni ad alta risoluzione per schermi più grandi. Ecco un esempio di configurazione:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" alt="Description" width="800" height="450">
</picture>

Dimensioni Corrette delle Immagini

Le immagini responsive sono solo una parte della soluzione perché responsive non significa che abbiano le dimensioni giuste. Adattare le dimensioni dell'immagine alla loro dimensione di visualizzazione è uno degli errori più comuni che vedo. Fornire un'immagine larga 2000px per un'area di visualizzazione di 500px spreca larghezza di banda e può rallentare notevolmente i tempi di caricamento.

Ottimizzazione dei File di Font

Quando l'elemento LCP è un testo renderizzato con un web font personalizzato, il file del font diventa la risorsa LCP. Ottimizza la Load Duration del font in questo modo:

• Usa il formato WOFF2: WOFF2 fornisce la migliore compressione per i web font, tipicamente il 30% più piccolo del WOFF e significativamente più piccolo dei file TTF o OTF.
• Crea un subset dei tuoi font: Se il tuo sito usa solo caratteri latini, crea un subset del font per rimuovere i set di caratteri non utilizzati (Cirillico, Greco, CJK). Strumenti come glyphhanger o pyftsubset possono automatizzare questo processo, riducendo spesso la dimensione del file del font del 50% o più.
• Limita le varianti di font: Ogni peso e stile (normale, grassetto, corsivo) è un download di file separato. Includi solo i pesi che il tuo design utilizza effettivamente.

2. Migliora le Prestazioni di Rete

Una volta ottimizzate le dimensioni delle risorse, il passo successivo è massimizzare la velocità di rete, o addirittura aggirare completamente la rete. Questo può essere ottenuto tramite:

Evitare Necessità di Rete con il Caching del Browser

Non c'è connessione di rete più veloce di una connessione di rete saltata. I browser hanno l'opzione di servire contenuti statici (invariabili) come immagini, script e fogli di stile direttamente dalla cache locale del browser. Configura il server per inviare le istruzioni di caching corrette al browser.

La configurazione più efficace è inviare un'intestazione Cache-Control come questa:

Cache-Control: public, max-age=31536000, immutable

• public: Consente alla risorsa di essere memorizzata nella cache sia dai browser che dalle cache intermedie.
• max-age=31536000: Imposta il tempo massimo in cui la risorsa è considerata fresca a un anno (31.536.000 secondi).
• immutable: Indica che la risorsa non cambierà nel tempo, prevenendo richieste di riconvalida non necessarie.

Affinché questa strategia funzioni in sicurezza, usa nomi di file con hash del contenuto (es. hero-abc123.webp) in modo che quando l'immagine cambia, cambi anche il nome del file, invalidando automaticamente la cache.

Compressione Brotli vs. Gzip

Per le risorse basate su testo (HTML, CSS, JavaScript, SVG), la compressione lato server è essenziale. Brotli, sviluppato da Google, supera costantemente Gzip nel rapporto di compressione mantenendo velocità di decompressione comparabili. Il seguente confronto illustra la differenza:

La configurazione ideale è pre-comprimere gli asset statici con Brotli a un alto livello di compressione (es. livello 11) durante il processo di build, e usare Gzip come fallback per i client che non supportano Brotli. La maggior parte dei CDN, incluso Cloudflare, gestisce questo automaticamente. Per maggiori dettagli sulla configurazione CDN, consulta la nostra guida su come configurare Cloudflare per le prestazioni.

HTTP/2 e HTTP/3: Vantaggi dei Protocolli Moderni

Il protocollo utilizzato per fornire le risorse ha un impatto significativo sulla Load Duration, specialmente quando più risorse vengono scaricate contemporaneamente.

• HTTP/2 ha introdotto il multiplexing, consentendo di inviare più richieste e risposte simultaneamente su una singola connessione TCP. Questo elimina il problema del blocco head-of-line di HTTP/1.1, in cui una risorsa lenta poteva ritardare tutte le altre. HTTP/2 supporta anche la compressione delle intestazioni (HPACK) e il server push.
• HTTP/3 fa un ulteriore passo avanti sostituendo TCP con QUIC, un protocollo basato su UDP. HTTP/3 elimina il blocco head-of-line a livello TCP (in cui un singolo pacchetto perso blocca tutti gli stream), fornisce un'instaurazione della connessione più rapida tramite 0-RTT (Zero Round Trip Time per visitatori di ritorno) e gestisce la perdita di pacchetti in modo più fluido. Questi vantaggi hanno un impatto particolare sul Time to First Byte ma riducono anche la Resource Load Duration complessiva.

Per verificare se HTTP/3 è abilitato, ispeziona semplicemente la tua rete con la scorciatoia Ctrl+Maiusc+I. Seleziona la scheda "Network" (Rete), fai clic destro sulle intestazioni di colonna della rete e assicurati che 'protocol' (protocollo) sia abilitato. Ricarica la pagina e controlla il protocollo. Per HTTP/3, il protocollo dovrebbe essere 'h3'.

Content Delivery Network (CDN)

Un CDN è una rete di server distribuiti che memorizzano nella cache e servono risorse statiche come immagini, CSS e JavaScript da posizioni più vicine all'utente. Questo riduce il tempo di viaggio dei dati (il round-trip time), che influisce direttamente sulla Resource Load Duration.

Oltre alla prossimità, i CDN moderni offrono numerosi vantaggi prestazionali che riducono la Load Duration:

• Ottimizzazione automatica delle immagini: Molti CDN possono comprimere, ridimensionare e convertire le immagini al volo. Ad esempio, Cloudflare Polish, Imgix e Cloudinary possono servire WebP o AVIF automaticamente in base all'intestazione Accept del browser.
• Caching edge: Le risorse statiche vengono memorizzate nella cache nei nodi edge in tutto il mondo, eliminando del tutto la necessità di recuperarle dal server di origine.
• Ottimizzazione del protocollo: I CDN tipicamente abilitano HTTP/2 e HTTP/3 per impostazione predefinita, insieme alla compressione Brotli, senza richiedere modifiche alla configurazione lato server.
• Riutilizzo della connessione: Poiché il CDN serve tutte le risorse da un singolo dominio, il browser riutilizza una singola connessione, eliminando il sovraccarico di più lookup DNS e handshake TLS.

I CDN specializzati per immagini possono andare oltre fornendo ottimizzazioni automatiche e in tempo reale come la conversione di formato, il ridimensionamento e la compressione.

Self-Hosting delle Risorse

Le risorse di rete importanti e iniziali dovrebbero per impostazione predefinita essere sempre ospitate sul server di origine (self-hosting). Il self-hosting elude la necessità di connettersi a server di terze parti, il che può causare ritardi considerevoli dovuti a ulteriori lookup DNS, negoziazioni SSL e configurazioni di connessione. Il self-hosting garantisce il riutilizzo di una singola connessione già aperta e riduce il sovraccarico derivante dallo stabilire connessioni separate. Le risorse in self-hosting consentono anche il pieno controllo sulla compressione e sulle policy di cache.

3. Ottimizza la Prioritizzazione delle Risorse

Dopo aver ridotto le dimensioni delle risorse e ottimizzato la rete, c'è anche il problema della competizione di rete. Quando più risorse vengono richieste contemporaneamente in condizioni di rete scarse, questo può rallentare considerevolmente il tempo di download delle risorse. Ecco perché ha senso minimizzare la competizione di rete programmando i download delle risorse.

Dai Priorità alle Risorse Critiche

Contrassegna le risorse essenziali, come immagini hero o CSS above-the-fold, con fetchpriority="high". Questo segnala al browser di scaricare per primi questi asset, evitando che vengano bloccati da script, widget o elementi di terze parti che non necessitano di un caricamento istantaneo. Dare priorità a queste risorse critiche riduce i tempi di caricamento per i contenuti che interessano maggiormente ai tuoi utenti. La combinazione di preload (per risolvere la scoperta tardiva) e fetchpriority="high" (per risolvere la contesa di rete) è la tecnica più potente per garantire che la risorsa LCP venga recuperata il prima e il più velocemente possibile.

<!-- For LCP images visible in the initial HTML -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- To improve discovery  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Riduci la Contesa di Rete

Snellisci i download iniziali differendo o caricando in lazy-loading gli asset non essenziali. Posticipa il caricamento per eventuali immagini o video non immediatamente visibili, nonché elementi di sfondo o secondari. Usare loading="lazy" per i media fuori schermo è un buon punto di partenza, mentre differire ulteriormente altri script e asset non essenziali libererà larghezza di banda e ridurrà la concorrenza con le tue risorse critiche, mantenendo il contenuto principale della tua pagina rapido da caricare e visualizzare. Non applicare mai loading="lazy" alla tua immagine LCP; questo è un anti-pattern critico che danneggerà il tuo punteggio.

4. Imposta le Speculation Rules

Le Speculation Rules (Regole di Speculazione) consentono ai browser di precaricare o pre-renderizzare le pagine web in base alla navigazione prevista dall'utente. Il prefetching elimina di fatto la sotto-parte Time to First Byte dell'LCP e non ha alcun impatto sulla Resource Load Duration. Il prerendering renderizza la pagina successiva in una scheda nascosta e scarica tutte le risorse della pagina. Questo elimina la maggior parte delle Load Duration per l'elemento LCP, come mostrato in questo esempio di suddivisione dell'LCP di una pagina prerenderizzata.

Prossimi Passi: Continua a Ottimizzare l'LCP

La Resource Load Duration è solo una delle quattro fasi dell'LCP. Dopo aver ottimizzato il tempo di download, esplora queste guide correlate:

• Risolvi e Identifica i Problemi LCP: La metodologia diagnostica completa per trovare e risolvere tutti i problemi LCP utilizzando dati sul campo e strumenti di laboratorio.
• Ottimizza l'Immagine LCP: Selezione del formato dell'immagine, immagini responsive, preloading ed errori comuni nell'ottimizzazione delle immagini.
• Resource Load Delay: Assicurati che il browser scopra la risorsa LCP il prima possibile. Questo è spesso un collo di bottiglia maggiore rispetto alla Load Duration stessa.
• Element Render Delay: Dopo il download della risorsa, assicurati che il browser possa renderizzarla immediatamente liberando il thread principale.