Ottimizza la durata del caricamento della risorsa 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 il Resource Load Delay rappresenti spesso una parte maggiore del tempo del LCP, ottimizzare la durata del download resta essenziale per ottenere un buon punteggio LCP.

Ottimizza la Resource Load Duration del LCP

Il Largest Contentful Paint (LCP) è una delle tre metriche di performance dei Core Web Vitals che misurano la user experience online. Il LCP rileva 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 del LCP che indica quanto tempo viene speso per recuperare la risorsa di rete per l'elemento LCP.

Cos'è la Resource Load Duration nel LCP?

La Resource Load Duration, spesso chiamata durata di caricamento, si riferisce al 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 dall'inizio del download dell'immagine fino al suo completamento da parte del browser. Per gli elementi LCP testuali, la durata di caricamento è in genere zero. La guida all'ottimizzazione del LCP di Google divide il LCP in quattro sotto-parti sequenziali, dove la Resource Load Duration è il tempo speso per scaricare fisicamente i byte della risorsa.

La Resource Load Duration si misura dal momento in cui il browser inizia a scaricare la risorsa LCP fino al completamento del download. Quattro fattori principali determinano la Resource Load Duration:

• Dimensioni del file: file più grandi richiedono tempi di download più lunghi.
• Velocità di rete: connessioni più lente estendono naturalmente la durata del caricamento.
• 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, aumentando i tempi di caricamento.

Come rilevare la Resource Load Duration

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

Ispezione di rete nei Chrome DevTools: usa la scorciatoia Ctrl + Maiusc + I per aprire i Developer Tools di Chrome, seleziona la scheda "Network" e ricarica la pagina. Cerca l'elemento LCP nelle richieste di rete (se vuoi conoscere l'elemento LCP, prova Core Web Vitals Visualizer). L'inspector di rete ti mostrerà quanto tempo ci è voluto per scaricare la risorsa.

Suggerimento Pro: abilita le righe di richiesta grandi per vedere dettagli aggiuntivi come la latenza del LCP, le dimensioni trasferite e le dimensioni effettive.

Usa i dati del Real User Monitoring (RUM):

I tool RUM registrano spesso i dati di attribuzione del LCP. I dati di attribuzione per il Largest Contentful Paint contengono informazioni sulla Resource Load Duration. Con questi dati, puoi creare grafici sull'andamento della durata di caricamento nel tempo o per pagina, e individuare le pagine o gli elementi che rallentano il tutto.

Guida passo-passo: per una misurazione di laboratorio precisa, registra una traccia nel pannello Performance. L'insight sulla scomposizione del LCP mostra la Resource Load Duration accanto alle altre tre sotto-parti. Guida completa: Diagnostica il LCP con il pannello Performance dei Chrome DevTools.

Come migliorare la durata di caricamento del 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 risolvono il problema: ridurre le dimensioni dei dati o ottimizzare la consegna dei dati.

1. Ottimizza le dimensioni del file

Ottimizzare le dimensioni del file riduce il numero di byte da inviare sulla rete. Meno dati significano meno 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. AVIF comprime fino al 50% in più 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 usato su oltre il 40% delle richieste di immagini, mentre l'adozione di AVIF è circa raddoppiata anno su anno ma rimane ancora sotto il 10%.

Scegliere l'impostazione di qualità giusta

Formati di 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, sembrerà identica all'originale a distanze di visione normali, ma a una frazione delle dimensioni del file. Fai sempre test con le tue immagini specifiche, perché la qualità ottimale dipende dal tipo di contenuto (fotografie contro illustrazioni contro immagini ricche di testo).

Automatizzare la compressione delle immagini con Sharp

Per l'ottimizzazione delle immagini a build-time, la libreria sharp è uno dei tool 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> responsivo con supporto ai formati moderni. Per i siti WordPress, plugin come ShortPixel o Imagify gestiscono questa conversione in automatico al caricamento.

Immagini responsive

L'elemento <picture> e l'attributo srcset servono dimensioni di immagine diverse in base allo schermo: versioni più piccole per il mobile, risoluzione più alta 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="Description" width="800" height="450">
</picture>

Dimensioni corrette dell'immagine

Le immagini responsive sono solo una parte della soluzione perché responsivo non significa dimensionato correttamente. Far corrispondere le dimensioni dell'immagine alla sua area 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 dei font

Quando l'elemento LCP è 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 offre la compressione migliore per i web font, di solito del 30% più piccolo rispetto a WOFF e nettamente inferiore ai file TTF o OTF.
• Fai il subset del font: se il tuo sito usa solo caratteri latini, fai un subset del font per rimuovere i set di caratteri inutilizzati (cirillico, greco, CJK). Tool come glyphhanger o pyftsubset possono automatizzare questo processo, riducendo spesso le dimensioni del file del font del 50% o più.
• Limita le varianti del font: ogni peso e stile (regular, bold, italic) è un download di file separato. Includi solo i pesi che il tuo design usa effettivamente.

2. Migliora le performance di rete

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

Bypassa le necessità di rete con la cache del browser

Non c'è connessione di rete più veloce di una connessione saltata. 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 consiste nell'inviare un header Cache-Control in questo modo:

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

• public: permette 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 inutili.

Affinché questa strategia funzioni in modo sicuro, usa nomi di file con hash del contenuto (ad esempio, hero-abc123.webp) così quando l'immagine cambia, cambia anche il nome del file, invalidando la cache in automatico.

Compressione Brotli contro Gzip

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

La configurazione ideale è pre-comprimere gli asset statici con Brotli a un livello di compressione elevato (ad esempio, livello 11) durante il processo di build, e usare Gzip come fallback per i client che non supportano Brotli. La maggior parte delle CDN, inclusa Cloudflare, lo gestisce automaticamente. Per maggiori dettagli sulla configurazione della CDN, leggi la nostra guida su come configurare Cloudflare per le performance.

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

Il protocollo di consegna è fondamentale quando il browser scarica più risorse contemporaneamente.

• L'HTTP/2 ha introdotto il multiplexing, che permette di inviare richieste e risposte multiple simultaneamente su una singola connessione TCP. Questo elimina il problema dell'head-of-line blocking di HTTP/1.1, in cui una risorsa lenta poteva ritardare tutte le altre. L'HTTP/2 supporta anche la compressione degli header (HPACK) e il server push.
• L'HTTP/3 fa un passo avanti sostituendo il TCP con QUIC, un protocollo basato su UDP. L'HTTP/3 elimina l'head-of-line blocking a livello TCP (dove un singolo pacchetto perso blocca tutti gli stream), fornisce uno stabilimento della connessione più veloce tramite 0-RTT (ripresa Zero Round Trip Time per i visitatori di ritorno) e gestisce la perdita di pacchetti in modo più fluido. Questi miglioramenti velocizzano principalmente il Time to First Byte, ma riducono anche la Resource Load Duration.

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

Content Delivery Network (CDN)

Una CDN è una rete di server distribuiti che mettono in 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 vicinanza, le CDN moderne offrono diversi vantaggi prestazionali che riducono la durata del caricamento:

• Ottimizzazione automatica delle immagini: molte CDN possono comprimere, ridimensionare e convertire le immagini al volo. Ad esempio, Cloudflare Polish, Imgix e Cloudinary possono servire WebP o AVIF in automatico in base all'header Accept del browser.
• Edge caching: le risorse statiche sono memorizzate nella cache sui nodi edge in tutto il mondo, eliminando del tutto la necessità di recuperarle dal server di origine.
• Ottimizzazione del protocollo: di default le CDN abilitano in genere HTTP/2 e HTTP/3, insieme alla compressione Brotli, senza richiedere modifiche alla configurazione lato server.
• Riutilizzo della connessione: poiché la CDN serve tutte le risorse da un singolo dominio, il browser riutilizza una singola connessione, eliminando l'overhead di lookup DNS multipli e handshake TLS.

Le CDN specializzate in immagini possono fare un ulteriore passo avanti fornendo ottimizzazioni automatiche e in tempo reale come la conversione del formato, il ridimensionamento e la compressione.

Self-hosting delle risorse

Di regola, le risorse di rete importanti e iniziali dovrebbero sempre essere ospitate sul server di origine. Il self-hosting aggira la necessità di connettersi a server di terze parti, che può causare notevoli ritardi a causa di ulteriori lookup DNS, negoziazioni SSL e configurazioni di connessione. Il self-hosting assicura il riutilizzo di una singola connessione già aperta e riduce l'overhead di stabilire connessioni separate. Le risorse in self-hosting permettono anche un controllo completo sulle policy di compressione e 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 il browser richiede più risorse contemporaneamente su una connessione lenta, queste competono per la larghezza di banda. Minimizza questa competizione pianificando i download delle risorse.

Dai priorità alle risorse critiche

Contrassegna le risorse essenziali, come le hero image o il 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 richiedono un caricamento istantaneo. Dare priorità a queste risorse critiche riduce il tempo di caricamento per i contenuti a cui i tuoi 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 assicurare 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 posticipando o caricando in lazy loading gli asset non essenziali. Rimanda il caricamento per qualsiasi immagine o video non immediatamente visibile, così come per 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à qualsiasi competizione con le tue risorse critiche, mantenendo rapido il caricamento e la visualizzazione del contenuto principale della tua pagina. 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 permettono ai browser di fare il prefetch o il prerender delle pagine web in base alla navigazione prevista dell'utente. Il prefetching elimina di fatto 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 quasi del tutto le durate di caricamento per l'elemento LCP, come mostrato in questo esempio di scomposizione del 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:

• Risolvi e identifica i problemi di LCP: la metodologia diagnostica completa per trovare e correggere tutti i problemi di LCP usando field data e tool 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. Spesso questo è un collo di bottiglia maggiore della durata del caricamento stessa.
• Element Render Delay: dopo che la risorsa è stata scaricata, assicurati che il browser possa disegnarla immediatamente liberando il main thread.