Ottimizza la Resource Load Duration del 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 delle quattro fasi sequenziali del LCP e misura il tempo necessario per scaricare la risorsa LCP via rete. Anche se il Resource Load Delay assorbe spesso la quota maggiore del tempo del LCP, ottimizzare la durata del download resta fondamentale per ottenere un buon punteggio LCP.

Ottimizza la Resource Load Duration del LCP

Il Largest Contentful Paint (LCP) è una delle tre metriche prestazionali dei Core Web Vitals che misurano l'esperienza utente online. Il LCP rileva il tempo necessario affinché l'elemento visivo più grande (un'immagine, un video o un blocco di testo) diventi visibile nel viewport. La Resource Load Duration è una sottofase del LCP che indica quanto tempo viene speso per scaricare via rete la risorsa dell'elemento LCP.

Cos'è la Resource Load Duration nel LCP?

La Resource Load Duration, spesso chiamata semplicemente Load Duration, indica il tempo necessario al browser per scaricare la risorsa di rete (ad esempio un'immagine) che costituirà l'elemento LCP. Per immagini e video, questo intervallo va dall'avvio del download della risorsa fino al suo completamento da parte del browser. Per gli elementi LCP di solo testo, la durata del caricamento è in genere pari a zero. La guida all'ottimizzazione del LCP di Google scompone il LCP in quattro sottofasi sequenziali: la Resource Load Duration è il tempo impiegato per scaricare effettivamente i byte della risorsa.

La Resource Load Duration si misura dal momento in cui il browser avvia il download della risorsa LCP fino al termine del download. Quattro fattori principali ne determinano la durata:

• Dimensioni del file: file più grandi richiedono tempi di download più lunghi.
• Velocità di rete: connessioni più lente allungano inevitabilmente la durata del caricamento.
• Reattività del server: i ritardi nella risposta del server rallentano il recupero della risorsa.
• Download simultanei: le risorse scaricate contemporaneamente competono per la banda, aumentando i tempi di caricamento.

Come individuare la Resource Load Duration

Esistono due modi efficaci per individuare e misurare la Resource Load Duration:

Ispezione di rete in Chrome DevTools: usa la scorciatoia Ctrl + Shift + I per aprire i Developer Tools di Chrome, seleziona la scheda "Network" e ricarica la pagina. Cerca l'elemento LCP tra le richieste di rete (se vuoi sapere qual è l'elemento LCP, prova Core Web Vitals Visualizer). Il pannello di rete ti mostrerà il tempo impiegato per scaricare la risorsa.

Consiglio pro: attiva le righe grandi per le richieste (large request rows) per visualizzare dettagli aggiuntivi come latenza del LCP, peso trasferito e dimensioni effettive.

Usa i dati di Real User Monitoring (RUM):

I tool RUM registrano spesso i dati di attribuzione del LCP. I dati di attribuzione del Largest Contentful Paint contengono informazioni sulla resource load duration. Con questi dati puoi tracciare i trend della durata di caricamento nel tempo o per singola pagina, individuando subito le pagine o gli elementi che causano rallentamenti.

Guida passo dopo passo: per una misurazione lab precisa, registra una traccia nel pannello Performance. L'insight sul breakdown del LCP mostra la resource load duration accanto alle altre tre sottofasi. Guida completa: Diagnostica il LCP con il pannello Performance di Chrome DevTools.

Come migliorare la Load Duration del LCP

I problemi di Resource Load Duration si verificano quando le risorse sono troppo pesanti o vengono distribuite lungo percorsi di rete non ottimali. Per intervenire ci sono due approcci principali: ridurre le dimensioni dei dati o ottimizzarne la distribuzione.

1. Ottimizza le dimensioni dei file

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

Usa formati di immagine moderni

AVIF e WebP sono le opzioni migliori per la compressione delle immagini. Sulle fotografie complesse, AVIF genera file fino al 50% più piccoli rispetto a WebP, senza alcuna perdita visibile di qualità. WebP offre una compatibilità browser più ampia e funziona bene per le immagini più semplici. Secondo il Web Almanac 2025, WebP viene ormai impiegato in oltre il 40% delle richieste di immagini, mentre l'adozione di AVIF è quasi raddoppiata di anno in anno, pur restando sotto il 10%.

Scegli la giusta impostazione di qualità

I formati di immagine moderni come WebP e AVIF consentono una notevole riduzione della qualità prima che il degrado visivo diventi percepibile. Di norma, un'impostazione di qualità tra 75 e 85 per WebP e tra 60 e 75 per AVIF risulta indistinguibile dall'originale alle normali distanze di visualizzazione, ma con una frazione del peso del file. Fai sempre dei test sulle immagini specifiche: la qualità ottimale dipende dal tipo di contenuto (fotografie, illustrazioni o immagini con molto testo).

Automatizza la compressione delle immagini con Sharp

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

const sharp = require('sharp');

// Converti in WebP con qualità ottimizzata
await sharp('input.jpg')
  .resize(1200)  // Ridimensiona alla larghezza massima necessaria
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Converti in AVIF con qualità ottimizzata
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Genera più dimensioni per immagini responsive
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 che supporta formati moderni. Per i siti WordPress, plugin come ShortPixel o Imagify gestiscono questa conversione in automatico durante l'upload.

Immagini responsive

L'elemento <picture> e l'attributo srcset servono a distribuire dimensioni di immagine differenti in base allo schermo: versioni più piccole per il mobile e risoluzioni più alte per gli 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="Descrizione" width="800" height="450">
</picture>

Dimensioni corrette delle immagini

Le immagini responsive sono solo una parte della soluzione: responsive non significa della dimensione corretta. Non far corrispondere le dimensioni dell'immagine alla sua dimensione di visualizzazione è uno degli errori più comuni che vedo. Inviare un'immagine larga 2000px per un'area di visualizzazione da 500px spreca banda e può rallentare notevolmente i tempi di caricamento.

Ottimizzazione dei file dei font

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

• Usa il formato WOFF2: WOFF2 garantisce la migliore compressione per i web font: in genere è il 30% più piccolo rispetto a WOFF e nettamente più leggero dei file TTF o OTF.
• Fai il subsetting dei font: se il sito usa solo caratteri latini, fai il subset del font per rimuovere i set di caratteri inutilizzati (cirillico, greco, CJK). Strumenti come glyphhanger o pyftsubset possono automatizzare l'operazione, riducendo spesso la dimensione del file del 50% o più.
• Limita le varianti del font: ogni spessore e stile (regular, bold, italic) richiede il download di un file separato. Includi solo i pesi effettivamente usati nel layout.

2. Migliora le prestazioni di rete

Una volta ottimizzate le dimensioni delle risorse, il passo successivo consiste nel massimizzare la velocità di rete, o addirittura nell'evitare del tutto la rete.

Evita la rete con la cache del browser

Non esiste connessione di rete più veloce di una richiesta evitata del tutto. I browser possono servire i contenuti statici (immagini, script, fogli di stile) direttamente dalla cache locale. Configura il server in modo da inviare al browser le istruzioni di caching corrette.

La configurazione più efficace consiste nell'inviare un header Cache-Control come questo:

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

• public: consente il salvataggio in cache sia ai browser sia alle cache intermedie.
• max-age=31536000: imposta a un anno (31.536.000 secondi) il tempo massimo in cui la risorsa è considerata aggiornata.
• immutable: indica che la risorsa non cambierà nel tempo, evitando richieste di riconvalida non necessarie.

Affinché questa strategia funzioni in sicurezza, usa file con hash nel nome (ad esempio hero-abc123.webp): quando l'immagine cambia, cambia anche il nome del file, invalidando la cache in automatico.

Compressione Brotli vs Gzip

Per le risorse testuali (HTML, CSS, JavaScript, SVG), la compressione lato server è fondamentale. Brotli, sviluppato da Google, supera costantemente Gzip nel rapporto di compressione, mantenendo velocità di decompressione paragonabili. Il confronto seguente evidenzia le differenze:

La configurazione ideale prevede di precomprimere gli asset statici con Brotli a un livello di compressione elevato (ad esempio il livello 11) durante il processo di build, usando Gzip come fallback per i client che non supportano Brotli. La maggior parte delle CDN, inclusa Cloudflare, gestisce questo processo in automatico. Per maggiori dettagli sulla configurazione della CDN, consulta la nostra guida su come configurare Cloudflare per le prestazioni.

HTTP/2 e HTTP/3: i vantaggi dei protocolli moderni

Il protocollo di trasmissione conta soprattutto quando il browser scarica più risorse contemporaneamente.

• HTTP/2 ha introdotto il multiplexing, consentendo di inviare contemporaneamente più richieste e risposte su una singola connessione TCP. Questo elimina il problema dell'head-of-line blocking di HTTP/1.1, in cui una sola risorsa lenta poteva ritardare tutte le altre. HTTP/2 supporta anche la compressione degli header (HPACK) e il server push.
• HTTP/3 va oltre sostituendo TCP con QUIC, un protocollo basato su UDP. HTTP/3 elimina l'head-of-line blocking a livello TCP (in cui la perdita di un singolo pacchetto blocca tutti gli stream), velocizza la creazione della connessione tramite 0-RTT (ripresa della sessione in Zero Round Trip Time per i visitatori di ritorno) e gestisce la perdita di pacchetti in modo più efficiente. Questi miglioramenti accelerano soprattutto il Time to First Byte, ma riducono anche la Resource Load Duration.

Per verificare se HTTP/3 è abilitato, apri il pannello di rete con la scorciatoia Ctrl + Shift + I. Seleziona la scheda Network, fai clic con il tasto destro sull'intestazione delle colonne e assicurati che 'Protocol' sia attivo. Ricarica la pagina e controlla il protocollo: per HTTP/3 leggerai 'h3'.

Content Delivery Network (CDN)

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

Oltre alla vicinanza geografica, le moderne CDN offrono diversi vantaggi prestazionali che riducono la durata del caricamento:

• Ottimizzazione automatica delle immagini: molte CDN comprimono, ridimensionano e convertono le immagini al volo. Ad esempio, Cloudflare Polish, Imgix e Cloudinary possono servire automaticamente WebP o AVIF in base all'header Accept del browser.
• Edge caching: le risorse statiche vengono salvate nella cache dei nodi edge in tutto il mondo, eliminando del tutto la necessità di scaricarle dal server di origine.
• Ottimizzazione dei protocolli: di norma le CDN abilitano HTTP/2 e HTTP/3 per impostazione predefinita, insieme alla compressione Brotli, senza richiedere modifiche alla configurazione del server.
• Riutilizzo della connessione: poiché la CDN distribuisce tutte le risorse da un unico dominio, il browser riutilizza una singola connessione, eliminando l'overhead di molteplici lookup DNS e handshake TLS.

Le Image CDN specializzate si spingono oltre, offrendo ottimizzazioni automatiche in tempo reale come conversione del formato, ridimensionamento e compressione.

Self-hosting delle risorse

Le risorse di rete critiche e richieste nelle prime fasi dovrebbero sempre, per impostazione predefinita, risiedere sul server di origine. Il self-hosting evita di doversi collegare a server di terze parti, operazione che può causare ritardi notevoli a causa di lookup DNS aggiuntivi, negoziazioni SSL e setup della connessione. Il self-hosting garantisce il riutilizzo di un'unica connessione già aperta e riduce l'overhead legato alla creazione di connessioni distinte. Inoltre, le risorse in self-hosting consentono il pieno controllo sulle policy di compressione e di cache.

3. Ottimizza la prioritizzazione delle risorse

Dopo aver ridotto il peso delle risorse e ottimizzato la rete, si presenta il problema della competizione sulla rete. Quando il browser richiede più risorse contemporaneamente su una connessione lenta, queste competono per la banda. Riduci al minimo questa contesa pianificando il download delle risorse.

Dai la priorità alle risorse critiche

Contrassegna le risorse essenziali, come l'immagine hero o il CSS above-the-fold, con fetchpriority="high". Questo segnala al browser di scaricare prima questi asset, evitando che vengano rallentati da script, widget o elementi di terze parti che non necessitano di un caricamento istantaneo. Dare priorità a queste risorse critiche riduce il tempo di caricamento dei contenuti a cui gli utenti tengono di più. 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 scaricata il prima possibile e alla massima velocità.

<!-- Per immagini LCP visibili nell'HTML iniziale -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- Per migliorare la scoperta -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Riduci la contesa di rete

Snellisci i download iniziali posticipando o caricando in lazy loading gli asset non essenziali. Rimanda il caricamento di immagini o video non immediatamente visibili, così come di elementi di sfondo o secondari. Usare loading="lazy" per i media fuori schermo (offscreen) è un buon punto di partenza; posticipare ulteriormente altri script e asset non essenziali libererà banda e ridurrà la competizione con le risorse critiche, mantenendo rapido il caricamento e la visualizzazione del contenuto principale della pagina. Non applicare mai loading="lazy" all'immagine LCP: è un anti-pattern critico che peggiorerà il punteggio.

4. Configura le Speculation Rules

Le Speculation Rules consentono ai browser di effettuare il prefetch o il prerender delle pagine web in base alla navigazione prevista dell'utente. Il prefetching elimina di fatto la sottofase Time to First Byte del LCP e non ha alcun impatto sulla Resource Load Duration. Il prerendering renderizza la pagina successiva in una scheda nascosta e ne scarica tutte le risorse. Questo azzera quasi del tutto la durata di caricamento dell'elemento LCP, come mostrato in questo esempio di breakdown del LCP di una pagina con prerendering.

Passi successivi: continua a ottimizzare il LCP

La Resource Load Duration è solo una delle quattro fasi del LCP. Dopo aver ottimizzato il tempo di download, prosegui con le altre fasi del LCP:

• Identifica e risolvi i problemi del LCP: la metodologia diagnostica completa per individuare e risolvere tutti i problemi del LCP usando field data e strumenti lab.
• Ottimizza l'immagine LCP: selezione del formato delle immagini, immagini responsive, preloading ed errori comuni di ottimizzazione.
• Resource Load Delay: fai in modo che il browser individui la risorsa LCP il prima possibile. Spesso questo ritardo rappresenta un collo di bottiglia più critico della durata di caricamento stessa.
• Element Render Delay: dopo aver scaricato la risorsa, assicurati che il browser possa eseguirne il paint immediatamente liberando il main thread.