Ottimizzare 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 dalla rete. Sebbene la Resource Load Delay spesso rappresenti una quota maggiore del tempo LCP, ottimizzare la durata del download resta essenziale per ottenere un buon punteggio LCP.

Ottimizzare la Resource Load Duration del LCP

Largest Contentful Paint (LCP) è una delle tre metriche di performance Core Web Vitals che misurano la user experience online. Il LCP misura il tempo necessario affinché l'elemento contenutistico più grande (un'immagine, un video o un blocco di testo) diventi visibile nel viewport. La Resource Load Duration è una sotto-parte del LCP che indica quanto tempo viene impiegato per recuperare la risorsa di rete dell'elemento LCP.

Cos'è la Resource Load Duration nel LCP?

La Resource Load Duration, spesso chiamata Load Duration, indica il tempo necessario al browser per scaricare la risorsa di rete (ad esempio un'immagine) che diventerà l'elemento LCP. Per immagini e video, questa durata va dal momento in cui l'immagine inizia a essere scaricata fino al completamento del download. Per gli elementi LCP basati su testo, la durata di caricamento è tipicamente zero. La guida all'ottimizzazione del LCP di Google suddivide il LCP in quattro sotto-parti sequenziali, dove la Resource Load Duration rappresenta il tempo effettivamente impiegato per scaricare i byte della risorsa.

La Resource Load Duration viene misurata dal momento in cui il browser inizia a scaricare la risorsa LCP fino al completamento del download. Quattro fattori principali determinano la durata del caricamento della risorsa:

• Dimensione del file: File più grandi richiedono tempi di download più lunghi.
• Velocità della rete: Connessioni più lente allungano naturalmente la durata del caricamento.
• Reattività del server: Ritardi nella risposta del server rallentano il recupero delle risorse.
• Download simultanei: Le risorse scaricate contemporaneamente competono per la banda disponibile, il che può aumentare i tempi di caricamento.

Come rilevare la Resource Load Duration

Esistono due metodi efficaci per identificare e misurare la durata di caricamento delle risorse:

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

Pro Tip: Abilita le righe di richiesta grandi per visualizzare dettagli aggiuntivi come la latenza LCP, la dimensione trasferita e la dimensione effettiva.

Utilizza dati Real User Monitoring (RUM):

Gli strumenti RUM spesso registrano dati di attribuzione del LCP. I dati di attribuzione del Largest Contentful Paint contengono informazioni sulla Resource Load Duration. Con questi dati, puoi visualizzare le tendenze della durata di caricamento nel tempo o per pagina e individuare le pagine o gli elementi che rallentano le prestazioni.

Come migliorare la Load Duration del LCP

I problemi di Resource Load Duration si verificano quando le risorse sono troppo grandi o vengono distribuite attraverso percorsi di rete non ottimali. Due approcci principali risolvono questo problema: ridurre la dimensione dei dati o ottimizzare la distribuzione dei dati.

1. Ottimizzare la dimensione dei file

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

Utilizzare formati immagine moderni

AVIF e WebP sono le migliori opzioni per la compressione delle immagini. AVIF comprime fino al 50% in meno rispetto a WebP per foto complesse, senza perdita di qualità visibile. WebP ha un supporto browser più ampio e funziona bene per immagini più semplici. Secondo il Web Almanac 2025, WebP è ora utilizzato in oltre il 40% delle richieste di immagini, mentre l'adozione di AVIF è circa raddoppiata anno su anno ma resta ancora sotto il 10%.

Scegliere l'impostazione di qualità corretta

I formati immagine moderni come WebP e AVIF consentono una riduzione significativa della qualità prima che il degrado visivo diventi percepibile. Come regola generale, un'impostazione di qualità tra 75 e 85 per WebP e tra 60 e 75 per AVIF risulterà identica all'originale a distanze di visualizzazione normali, ma con una frazione della dimensione del file. Testa sempre con le tue immagini specifiche, poiché la qualità ottimale dipende dal tipo di contenuto (fotografie vs. illustrazioni vs. immagini con molto 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 utilizzati 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');

// 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 ai formati moderni. Per i siti WordPress, plugin come ShortPixel o Imagify gestiscono questa conversione automaticamente al caricamento.

Immagini responsive

L'elemento <picture> e l'attributo srcset servono immagini di dimensioni diverse in base allo schermo: versioni più piccole per il mobile, risoluzioni più alte 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 parte della soluzione, perché responsive non significa che siano dimensionate correttamente. Far corrispondere le dimensioni dell'immagine alla loro area di visualizzazione è uno degli errori più comuni che riscontro. Servire un'immagine larga 2000px per un'area di visualizzazione di 500px spreca banda e può rallentare notevolmente i tempi di caricamento.

Ottimizzazione dei file dei font

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

• Usa il formato WOFF2: WOFF2 offre la migliore compressione per i web font, tipicamente il 30% più piccolo di WOFF e significativamente più piccolo dei file TTF o OTF.
• Fai il subset dei font: Se il tuo sito utilizza solo caratteri latini, rimuovi i set di caratteri non utilizzati (cirillico, greco, CJK) tramite il subset. Strumenti come glyphhanger o pyftsubset possono automatizzare questo processo, spesso riducendo la dimensione del file del font del 50% o più.
• Limita le varianti del font: Ogni peso e stile (regular, bold, italic) è un download separato. Includi solo i pesi che il tuo design utilizza effettivamente.

2. Migliorare le prestazioni di rete

Una volta ottimizzate le dimensioni delle risorse, il passo successivo è massimizzare la velocità di rete, o addirittura bypassare completamente la rete.

Bypassare la rete con il caching del browser

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

La configurazione più efficace è inviare un header Cache-Control come questo:

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

• public: Consente la memorizzazione della risorsa sia nei browser che nelle 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 rivalidazione non necessarie.

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

Brotli vs. Gzip Compression

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 livello di compressione alto (ad esempio livello 11) durante il processo di build, e utilizzare 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 sulla configurazione di Cloudflare per le prestazioni.

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

Il protocollo di distribuzione è più rilevante quando il browser scarica più risorse contemporaneamente.

• HTTP/2 ha introdotto il multiplexing, permettendo l'invio simultaneo di più richieste e risposte su una singola connessione TCP. Questo elimina il problema dell'head-of-line blocking di HTTP/1.1, dove una 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 (dove un singolo pacchetto perso blocca tutti gli stream), fornisce un'apertura della connessione più rapida tramite 0-RTT (Zero Round Trip Time per i visitatori di ritorno) e gestisce la perdita di pacchetti in modo più efficiente. Questi miglioramenti accelerano principalmente il Time to First Byte, ma riducono anche la Resource Load Duration.

Per verificare se HTTP/3 è abilitato, ispeziona semplicemente la tua rete con la scorciatoia Ctrl+Shift+I. Seleziona la scheda network, fai clic destro sulle intestazioni delle colonne di rete e assicurati che 'protocol' sia abilitato. Ricarica la pagina e controlla il protocollo. Per HTTP/3, il protocollo dovrebbe indicare 'h3'.

Content Delivery Network (CDN)

Un 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 percorrenza dei dati (il round-trip time), il che influisce direttamente sulla Resource Load Duration.

Oltre alla prossimità, i CDN moderni offrono diversi vantaggi prestazionali che riducono la durata del caricamento:

• 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'header Accept del browser.
• Edge caching: Le risorse statiche vengono memorizzate nella cache sui nodi edge in tutto il mondo, eliminando 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 del 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ù ricerche DNS e handshake TLS.

I CDN specializzati per le immagini possono spingersi oltre fornendo ottimizzazioni automatiche in tempo reale come conversione del formato, ridimensionamento e compressione.

Self-hosting delle risorse

Le risorse importanti e necessarie nelle prime fasi dovrebbero sempre essere ospitate sul server di origine per impostazione predefinita. Il self-hosting evita la necessità di connettersi a server di terze parti, che possono causare ritardi considerevoli a causa di ricerche DNS aggiuntive, negoziazioni SSL e aperture di connessione. Il self-hosting garantisce il riutilizzo di una singola connessione già aperta e riduce il sovraccarico dell'apertura di connessioni separate. Le risorse self-hosted consentono inoltre il pieno controllo sulle policy di compressione e caching.

3. Ottimizzare la prioritizzazione delle risorse

Dopo aver ridotto la dimensione delle risorse e ottimizzato la rete, rimane il problema della competizione di rete. Quando il browser richiede più risorse contemporaneamente su una connessione lenta, queste competono per la banda. Minimizza questa competizione pianificando i download delle risorse.

Prioritizzare le risorse critiche

Contrassegna le risorse essenziali, come le immagini hero o il CSS above-the-fold, con fetchpriority="high". Questo segnala al browser di scaricare questi asset per primi, evitando che vengano rallentati da script, widget o elementi di terze parti che non necessitano di caricamento immediato. Prioritizzare queste risorse critiche riduce il tempo di caricamento per i contenuti che interessano di più 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 più presto e 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">

Ridurre la contesa di rete

Ottimizza i download iniziali rimandando o caricando in modo lazy gli asset non essenziali. Posticipa il caricamento di immagini o video non immediatamente visibili, così come di elementi secondari o di sfondo. Utilizzare loading="lazy" per i media fuori schermo è un buon punto di partenza, mentre rimandare ulteriormente altri script e asset non essenziali libererà banda e ridurrà la competizione con le risorse critiche, mantenendo il contenuto principale della pagina veloce da caricare e visualizzare. Non applicare mai loading="lazy" all'immagine LCP: questo è un anti-pattern critico che peggiorerà il tuo punteggio.

4. Configurare le Speculation Rules

Le Speculation Rules consentono ai browser di prefetchare o prerenderizzare le pagine web in base alla navigazione prevista dell'utente. Il prefetching elimina efficacemente la sotto-parte Time to First Byte del LCP e non ha 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 durate di caricamento per l'elemento LCP, come mostrato in questo esempio di suddivisione LCP di una pagina prerenderizzata.

Prossimi passi: 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:

• Individuare e correggere i problemi di LCP: La metodologia diagnostica completa per trovare e risolvere tutti i problemi di LCP utilizzando dati di campo e strumenti di laboratorio.
• Ottimizzare l'immagine LCP: Selezione del formato immagine, immagini responsive, preloading e 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 durata di caricamento stessa.
• Element Render Delay: Dopo il download della risorsa, assicurati che il browser possa visualizzarla immediatamente liberando il main thread.