Ottimizza il ritardo di caricamento della risorsa LCP

Questa guida fa parte dell'hub dedicato al Largest Contentful Paint (LCP). Il Resource Load Delay è spesso il principale fattore che contribuisce a un punteggio LCP scarso, specialmente nei siti SPA! 

Ottimizza il Resource Load Delay del LCP

Il Largest Contentful Paint (LCP) è composto da quattro sottofasi: TTFB, Resource Load Delay, Resource Load Duration ed Element Render Delay. 

Un consiglio rapido: se il tuo LCP è un'immagine, sarà quasi sempre peggiore rispetto a un testo. Devi tracciare i tipi di elementi LCP nei tuoi dati RUM, altrimenti navighi al buio.

Cos'è il Resource Load Delay?

Il Resource Load Delay è il tempo che passa tra il TTFB e il momento in cui il browser avvia il download della risorsa LCP. In sostanza, un browser dovrebbe accodare una risorsa LCP (ad esempio l'immagine LCP)  il prima possibile. Se ciò non accade, molto probabilmente è perché il browser non riesce a individuarla subito o non la ritiene abbastanza importante.

Un valore elevato indica un problema architetturale (il browser non trova l'URL della risorsa nel payload HTML iniziale). Questo Resource Load Delay può essere visto come il tempo che il browser impiega per capire che la risorsa LCP è necessaria e decidere di recuperarla.

È anche importante capire che il Resource Load Delay si verifica prima che la risorsa venga effettivamente caricata. Ecco perché non ha nulla a che fare con le immagini responsive o con i nuovi formati di immagine come WebP o AVIF.

Per gli elementi LCP testuali e renderizzati con un font di sistema, questo Resource Load Delay è solitamente pari a zero, poiché non è necessario recuperare alcuna risorsa esterna. Valori di Resource Load Delay più elevati sono specifici per gli elementi LCP che dipendono da una risorsa di rete esterna, come un'immagine o un file video.

In che modo il browser trova l'elemento LCP?

Per ridurre il Resource Load Delay, devi capire come i browser scoprono le risorse (o almeno come scoprono l'elemento LCP). I browser utilizzano due meccanismi: un percorso veloce e un percorso lento. Per prima cosa devi assicurarti che l'elemento LCP si trovi nel "percorso veloce".

• Il DOM Parser (percorso lento): è il parser principale del browser ed è estremamente complesso. Costruisce la pagina intera  leggendo l'HTML, i fogli di stile e interagendo con JavaScript. Questo è il percorso lento perché può essere rallentato e interrotto dal download e dall'esecuzione di altri file, creando una catena di dipendenze che introduce ritardi.
• Il Preload Scanner (percorso veloce): poiché il DOM Parser è (relativamente) lento, i browser dispongono di uno scanner secondario ultra-veloce che analizza la pagina rapidamente alla ricerca di risorse scaricabili e non viene bloccato  da nulla. Se trova tag <script>, <img> non-lazy o tag <link>, li mette subito in coda per il download, prima che il CSS venga analizzato o il JavaScript eseguito. Questo è il percorso ottimale per qualsiasi risorsa critica.

L'intera strategia per ottimizzare il Resource Load Delay si basa su un unico principio: assicurarsi che l'URL della risorsa LCP sia individuabile il prima possibile dal preload scanner.

Questo significa due cose per un elemento LCP:

1. Assicurati che il preload scanner possa trovarlo utilizzando un normale tag immagine che non abbia la proprietà loading="lazy".
2. Assicurati che il preload scanner non dia priorità a troppe risorse meno importanti.

Perché il Load Delay è importante per i Core Web Vitals

Gli sviluppatori alle prime armi spesso pensano che l'LCP sia un problema di "dimensioni del file". Questo porta i team a concentrarsi su compressione delle immagini, formati di immagine moderni e immagini responsive. È un errore. La nostra ricerca sui Core Web Vitals mostra che il singolo collo di bottiglia più grande nell'LCP è il TTFB (48%), seguito dal Load Delay che occupa il (24%), mentre il tempo di caricamento incide solo per il 10% e il Render Delay per il 17%.

Il punto è che il Load Delay è quasi completamente risolvibile, mentre il TTFB esisterà sempre. Questo rende il Load Delay l'elemento con il maggior potenziale di ottimizzazione.

Come rilevare il Resource Load Delay

Per risolvere il Resource Load Delay, devi prima misurarlo accuratamente. Il flusso di lavoro è sempre lo stesso: controlla con CrUX per definire il problema con i dati degli utenti reali (RUM), e solo dopo passa a Chrome DevTools per un'analisi approfondita.

Fase 1: Controlla con CrUX.

CrUX rappresenta i dati di campo degli utenti reali di Google, disponibili pubblicamente per gli utenti Chrome idonei, forniti come visualizzazione a scorrimento di 28 giorni dei tuoi Core Web Vitals al 75° percentile. Ti dice se un numero è buono o insufficiente, ma non indica chi, cosa o perché. Poiché Google si affida ai dati CrUX, questa è la tua migliore fonte di verità per iniziare.

Vai su cruxvis.withgoogle.com, inserisci il tuo sito web, naviga su Loading Performance e clicca su Largest Contentful Paint (LCP) image subparts

Fase 2: Analizza i dati di campo (RUM)

I RUM raccolgono i Core Web Vitals di tutti i tuoi utenti reali e offrono una vista molto più specifica e dettagliata. Ti dicono chi e cosa, filtrati come preferisci (e questa informazione è preziosissima), ma non il perché.

Fase 3: Diagnostica con DevTools

Una volta che i dati RUM hanno identificato una pagina target e l'elemento LCP, usi Chrome DevTools per diagnosticarne la causa. L'obiettivo è riprodurre il problema e misurare le sottofasi dell'LCP per ottenere un valore preciso del Resource Load Delay. DevTools è anche lo strumento con cui esegui un'analisi del main thread per vedere esattamente quali task sono in esecuzione e bloccano potenzialmente il processo di rendering.

Guida passo-passo al pannello Performance di Chrome DevTools

Il pannello Performance di Chrome DevTools è uno strumento indispensabile per sezionare l'LCP e quantificare il Load Delay.

1. Configurazione:

• Apri Chrome DevTools facendo clic con il tasto destro sulla pagina e selezionando "Ispeziona" o usando la scorciatoia Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac).
• Naviga nella scheda Performance.
• Assicurati che la casella Web Vitals sia abilitata nelle impostazioni di acquisizione. Questo sovrapporrà le informazioni sui Core Web Vitals nella timeline delle prestazioni.
• Per simulare condizioni utente reali, applica il throttling di CPU e rete. Un rallentamento della CPU pari a "4x" e un profilo di rete "Fast 3G" o "Slow 4G" sono punti di partenza comuni per i test su dispositivi mobili.

2. Registrazione di un profilo di prestazioni:

• Fai clic sul pulsante "Record and reload page" (l'icona con la freccia circolare) nel pannello Performance. Questo avvierà la registrazione, ricaricherà la pagina e interromperà la registrazione una volta che la pagina sarà completamente caricata.

3. Analisi e interpretazione:

• Traccia Timings: nella visualizzazione principale della timeline, individua la traccia Timings. Vedrai un marcatore contrassegnato come LCP. Passando il mouse su questo marcatore, l'elemento LCP corrispondente verrà evidenziato nello screenshot del viewport principale e verrà mostrato il tempo totale dell'LCP.
• Scomposizione dell'LCP per fasi: fai clic sul marcatore LCP nella traccia Timings. Nella scheda Summary in basso nel pannello, troverai una scomposizione dettagliata delle tempistiche dell'LCP. Questa scomposizione mostra chiaramente la durata di ciascuna delle quattro sottofasi, incluso il Load Delay, misurato in millisecondi. Questo valore è la misurazione più diretta e precisa del Resource Load Delay per quel caricamento di pagina specifico.
• Analisi del main thread: mentre esamini la timeline, cerca nella traccia Main eventuali long task (blocchi di attività contrassegnati da un triangolo rosso). Se questi long task si verificano dopo che il caricamento della risorsa LCP è terminato ma prima del marcatore LCP, probabilmente stanno contribuendo all'Element Render Delay, un problema correlato ma distinto.

Cause comuni e soluzioni ad alto impatto

Un Resource Load Delay elevato è causato da due fattori: la risorsa LCP viene scoperta tardi, oppure le viene assegnata una priorità di recupero bassa. Ecco gli errori architetturali più comuni e le relative soluzioni.

Causa: LCP caricato tramite CSS

Il problema: il preload scanner non analizza i file CSS. Quando l'immagine LCP è definita con una background-image CSS, il suo URL è invisibile a questo scanner veloce. Il browser può scoprire l'immagine solo dopo aver scaricato l'HTML, trovato il link al file CSS, scaricato il file CSS, costruito il CSSOM e infine applicato lo stile. Questa catena di dipendenze causa direttamente un Resource Load Delay elevato. Per ulteriori informazioni su questo pattern, consulta la nostra guida su come rinviare le immagini di sfondo.

La soluzione: l'implementazione corretta consiste nell'evitare l'uso di background-image per qualsiasi elemento LCP critico. Usa invece un tag <img> standard. In questo modo l'URL dell'immagine viene inserito direttamente nell'HTML, dove il preload scanner può trovarlo immediatamente. Puoi ottenere lo same risultato visivo con il CSS.

Esempio di implementazione:

Anti-pattern (non fare così):

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Best practice (fai così):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Un testo alternativo descrittivo per l'immagine hero"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Titolo della pagina</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalente a top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* Questa proprietà imita background-size: cover */
      z-index: -1; /* Posiziona l'immagine dietro agli altri contenuti */
    }
    

Questa implementazione fornisce lo stesso risultato visivo ma rende l'immagine LCP individuabile al primissimo momento possibile, riducendo al minimo il suo Resource Load Delay.

Causa: Client-Side Rendering e iniezione di JavaScript

Il problema: le applicazioni che utilizzano framework di client-side rendering (CSR) come React o Vue spesso servono uno scheletro HTML minimo. Il contenuto effettivo, incluso il tag LCP <img>, viene inserito nel DOM da JavaScript solo dopo che i grandi bundle del framework sono stati scaricati, analizzati ed eseguiti. Questo processo nasconde fondamentalmente la risorsa LCP al preload scanner, creando un'elevata latenza di scoperta.

La soluzione: la soluzione più efficace consiste nello spostare il rendering iniziale dal client al server.

• Server-Side Rendering (SSR) o Static Site Generation (SSG): pattern architetturali come SSR o SSG generano l'HTML completo sul server. Il browser riceve un documento completo contenente il tag <img> e il suo attributo src, rendendo la risorsa LCP immediatamente individuabile dal preload scanner. Questa è l'architettura richiesta per qualsiasi pagina in cui le prestazioni siano critiche.
• Ottimizzazioni specifiche del framework: i framework moderni offrono anche ottimizzazioni integrate. Ad esempio, il componente <Image> di Next.js ha una proprietà priority. Impostarla su true indica al framework di aggiungere automaticamente i corretti attributi <link rel="preload"> e fetchpriority="high", garantendo che l'immagine venga scoperta e recuperata con la priorità corretta.

Causa: utilizzo di loading="lazy" sull'immagine LCP

Il problema: si tratta di un errore frequente e ad alto impatto. L'attributo loading="lazy" è un'istruzione diretta al browser per ritardare il recupero di un'immagine finché non si trova vicino al viewport. Sebbene questa sia l'ottimizzazione corretta per le immagini below-the-fold, applicarla a un elemento LCP above-the-fold è controproducente. Il preload scanner del browser è progettato per ignorare le immagini con loading="lazy", il che garantisce una scoperta tardiva e un Resource Load Delay elevato.

La soluzione: la soluzione richiede diligenza.

• Rimuovere loading="lazy" dall'immagine LCP: qualsiasi immagine che possa essere l'elemento LCP non deve avere l'attributo loading="lazy". Il comportamento predefinito del browser è loading="eager", che è l'impostazione corretta per i contenuti critici above-the-fold. Omettere completamente l'attributo loading ha lo stesso effetto.
• Verificare e configurare gli strumenti di terze parti: devi anche verificare gli strumenti di terze parti. Molte piattaforme CMS come WordPress e vari plugin di ottimizzazione delle immagini applicano automaticamente il lazy loading a tutte le immagini. È essenziale configurare questi strumenti per escludere l'immagine LCP da questo comportamento. Spesso ciò comporta la creazione di una regola di esclusione per le prime una o due immagini della pagina.

Causa: struttura HTML non ottimale e documenti di grandi dimensioni

Il problema: il preload scanner elabora il documento HTML dall'alto verso il basso. Se risorse non critiche ma ad alto consumo di banda, come le icone dell'header o gli script dei widget di chat, sono posizionate nel tag <body> più in alto rispetto all'elemento LCP, vengono scoperte e messe in coda per il download per prime. Ciò consuma la larghezza di banda di rete iniziale e può ritardare il download della risorsa LCP. Anche un documento HTML di grandi dimensioni può rappresentare un problema: se l'elemento LCP non si trova nel primo blocco di dati ricevuto dal browser (circa 14 KB), la sua scoperta viene ritardata di almeno un round trip di rete.

La soluzione: ottimizza la struttura e la priorità dei contenuti all'interno dell'HTML.

• Riordinare l'HTML: quando possibile, assicurati che il tag <img> o il blocco di testo per l'elemento LCP appaia il prima possibile all'interno del tag <body>.
• De-prioritizzare le immagini non critiche: per le immagini non essenziali che devono apparire all'inizio dell'HTML (come le icone in un header), applica loading="lazy". Questo indica al preload scanner di saltarle, preservando la coda di download per l'elemento LCP.
• Differire gli script non essenziali: gli script per web analytics, pubblicità o widget di social media sono raramente critici per il rendering iniziale. Sposta i tag <script> alla fine del <body> o usa l'attributo defer. Questo evita che blocchino il parser o competano per la larghezza di banda di rete con la risorsa LCP.

Prioritizzazione avanzata con i Resource Hints

Una volta che la risorsa LCP è individuabile nell'HTML, puoi usare i resource hint per fornire al browser istruzioni più esplicite su come recuperarla. Questi hint forniscono un controllo granulare sulla scoperta e sulla prioritizzazione.

Forzare la scoperta anticipata con <link rel="preload">

<link rel="preload"> non è un hint, è una direttiva. Costringe il browser a scaricare una risorsa con priorità elevata, anche se non è ancora individuabile dal parser principale. Posizionarlo nella sezione <head> del tuo HTML è il modo più diretto per risolvere i problemi di scoperta tardiva per risorse come font, immagini di sfondo CSS o immagini LCP situate in profondità nel DOM. Per dettagli di implementazione ed esempi completi, consulta la nostra guida dedicata su come precaricare l'immagine LCP.

Meccanismo

Quando un link di preload viene inserito nella sezione <head> del documento HTML, il preload scanner lo individua e mette subito in coda la risorsa specificata per il download. Questo è l'ideale per risorse come i font caricati tramite @font-face in un foglio di stile esterno, gli LCP che usano una background-image CSS (sebbene sia preferibile usare un tag <img>) o un'immagine LCP posizionata in profondità all'interno di una struttura DOM complessa.

Preloading responsive

Un dettaglio di implementazione cruciale è richiesto per il preloading di immagini responsive. Per garantire che il browser precarichi l'immagine della dimensione corretta per il viewport dell'utente ed evitare un inutile doppio download, il tag <link rel="preload"> deve includere gli attributi imagesrcset e imagesizes che rispecchiano perfettamente gli attributi del tag <img> corrispondente.

Esempio di preloading responsive:

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="Un testo alternativo descrittivo"
     fetchpriority="high"
     width="1200" height="675">
    

Potenziale insidia

Il preloading risolve le tempistiche di recupero (Load Delay e Load Duration) ma non quelle di rendering (paint timing). Se il main thread è bloccato da JavaScript pesante o CSS render-blocking al momento dell'arrivo dell'immagine precaricata, questa dovrà comunque attendere di essere renderizzata, il che può spostare il collo di bottiglia dal Load Delay all'Element Render Delay.

fetchpriority="high" e la coda delle priorità del browser

L'attributo fetchpriority è un hint che segnala l'importanza relativa del download di una risorsa. Ti consente di influenzare la priorità di una risorsa all'interno della coda di download del browser.

Come funziona la priorità del browser

Quando il browser scopre le risorse durante il caricamento della pagina, assegna a ciascuna un livello di priorità interna. Per impostazione predefinita, le immagini nel viewport iniziano con una priorità "Low" e vengono successivamente aggiornate a "High" una volta che il browser completa il layout e ne determina la visibilità. Questo aggiornamento richiede che il browser scarichi e analizzi prima il CSS, creando un ritardo. L'attributo fetchpriority="high" bypassa completamente questo processo impostando l'immagine a priorità "High" fin dal momento in cui viene scoperta. Questo è particolarmente impattante per le immagini LCP perché elimina il ritardo dell'aggiornamento della priorità.

preload rispetto a fetchpriority

Questi due hint servono a scopi diversi ma complementari. Il preload influisce su quando una risorsa viene scoperta e aggiunta alla coda. fetchpriority influisce sul suo livello di priorità una volta inserita in coda. Comprendere questa distinzione è fondamentale: il preload risolve la scoperta tardiva, mentre fetchpriority risolve la bassa prioritizzazione. Per molte immagini LCP che sono già presenti nell'HTML, il solo fetchpriority può essere sufficiente. Per una guida completa su come questi due elementi interagiscono, consulta il nostro articolo sulla prioritizzazione delle risorse.

Best practice per l'LCP

Per l'immagine LCP, la strategia ottimale consiste nell'usarli insieme. Primo, assicurati una scoperta anticipata posizionando il tag <img> all'inizio dell'HTML o usando il preload. Secondo, aggiungi fetchpriority="high" direttamente al tag <img> (e al link di preload, se utilizzato). Questa combinazione garantisce che la risorsa non solo venga scoperta presto, ma che le venga anche data la priorità più alta possibile per vincere la competizione per la larghezza di banda di rete contro altre risorse come fogli di stile o font.

Esempio:

<img src="lcp-image.jpg" fetchpriority="high" alt="Un'immagine hero critica">

Quando usare fetchpriority="low"

L'attributo fetchpriority non serve solo ad aumentare la priorità. Puoi anche usare fetchpriority="low" per de-prioritizzare risorse non critiche che competono per la larghezza di banda con l'immagine LCP. I candidati comuni includono immagini above-the-fold che non sono l'elemento LCP (come piccole icone o avatar nell'header) e risorse precaricate che sono necessarie ma non urgenti. Abbassando esplicitamente la priorità di queste risorse concorrenti, crei più spazio di banda per l'immagine LCP.

<!-- Immagine LCP: priorità alta -->
<img src="hero.jpg" fetchpriority="high" alt="Immagine hero" width="1200" height="600">

<!-- Immagine above-fold non critica: priorità bassa -->
<img src="avatar.jpg" fetchpriority="low" alt="Avatar dell'autore" width="48" height="48">

Impatto dimostrato

In un caso di studio relativo a Google Flights, l'aggiunta di fetchpriority="high" all'immagine di sfondo LCP della pagina ha migliorato il tempo di LCP da 2,6 secondi a 1,9 secondi, un miglioramento di 700 ms.

Ottimizzare le connessioni a terze parti: preconnect e dns-prefetch

Il problema

Se la tua risorsa LCP è ospitata su un dominio di terze parti, come una CDN di immagini o un provider di font come Google Fonts, il browser deve stabilire una nuova connessione di rete verso quel dominio. Questo processo comporta una ricerca DNS, un handshake TCP e una negoziazione TLS, che devono essere completati prima di poter avviare il download del primo byte della risorsa. Questo tempo di configurazione della connessione contribuisce direttamente al Resource Load Delay per le risorse cross-origin.

Le soluzioni

• preconnect: questo hint indica al browser di eseguire in background e in anticipo la configurazione completa della connessione (DNS, TCP e TLS) per un'origine di terze parti specificata. Quando la risorsa viene effettivamente richiesta, la connessione è già attiva ("warm"), eliminando la latenza di configurazione. Questa soluzione è altamente efficace e consigliata per uno o due dei domini di terze parti più critici che servono risorse LCP.
• dns-prefetch: si tratta di un hint più leggero che esegue solo la ricerca DNS per un dominio. Consente di risparmiare meno tempo rispetto a preconnect ma ha un supporto del browser più ampio ed è utile come fallback o per domini di terze parti meno critici.

Best practice di implementazione

Per garantire la massima compatibilità, fornisci entrambi gli hint. Il browser utilizzerà preconnect se supportato e passerà a dns-prefetch in caso contrario. L'attributo crossorigin è essenziale per le risorse recuperate tramite CORS, come i font.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

Tabella: confronto dei Resource Hint per l'ottimizzazione dell'LCP

Per prevenire un utilizzo errato e chiarire i ruoli distinti di questi potenti hint, la tabella seguente fornisce un riepilogo comparativo.

Strategie olistiche e orientate al futuro

Oltre ai resource hint, decisioni architetturali più ampie possono ridurre ulteriormente il Resource Load Delay.

Il ruolo di una CDN moderna

Una Content Delivery Network (CDN) è una tecnologia fondamentale per le prestazioni web che riduce indirettamente ma significativamente il Resource Load Delay, in particolare per le risorse LCP.

• Riduzione dell'overhead di connessione: distribuendo le risorse su una rete globale di server, una CDN posiziona i contenuti geograficamente più vicini all'utente. Questo riduce intrinsecamente il round-trip time (RTT) richiesto per la ricerca DNS, l'handshake TCP e la negoziazione TLS, che sono tutti componenti del tempo di configurazione della connessione. Per un'immagine LCP ospitata su una CDN, ciò riduce direttamente il suo Load Delay.
• CDN di immagini (Image CDN): le CDN di immagini specializzate offrono un duplice vantaggio. Forniscono il vantaggio di prossimità di una CDN standard, automatizzando al contempo molte ottimizzazioni complesse che riducono la Resource Load Duration, come il ridimensionamento delle immagini al volo, la compressione e la conversione in formati moderni come AVIF e WebP.
• Protocolli avanzati: molte CDN moderne utilizzano HTTP/3, che fa uso di QUIC invece di TCP. HTTP/3 riduce il tempo di configurazione della connessione e attenua l'head-of-line blocking, portando a una distribuzione delle risorse generalmente più rapida ed efficiente.

Eliminare completamente il ritardo con le Speculation Rules

L'API Speculation Rules può eliminare completamente il ritardo LCP per le navigazioni successive.

Meccanismo

Questa API consente agli sviluppatori di informare in modo dichiarativo il browser su quali URL sia probabile che l'utente navighi successivamente. In base a queste regole, il browser può scegliere di eseguire il prerendering di una pagina di destinazione in una scheda nascosta in background, prima ancora che l'utente faccia clic sul link.

Impatto sull'LCP

Quando l'utente fa clic su un link a una pagina con prerendering, la navigazione è praticamente istantanea. La pagina è già stata completamente caricata e renderizzata in background. Per questa navigazione, il TTFB, il Resource Load Delay, la Resource Load Duration e l'Element Render Delay vengono tutti ridotti a quasi zero dal punto di vista dell'utente.

Esempio di caso d'uso

Su una pagina di categoria di e-commerce, le regole di speculazione potrebbero essere utilizzate per eseguire il prerendering delle pagine di dettaglio del prodotto per i primi articoli dell'elenco. Quando un utente fa clic su uno di questi prodotti, la pagina appare istantaneamente.

Sintesi dei casi di studio: dalla teoria alla pratica

Queste ottimizzazioni hanno un impatto reale e misurabile.

• Caso 1: Il potere trasformativo del preloading: un esperimento condotto da DebugBear su una pagina con un Load Delay elevato fornisce un esempio lampante. L'immagine LCP era nascosta in una catena di richieste, facendo sì che il Resource Load Delay rappresentasse ben il 75% del tempo di LCP totale. Implementando un singolo hint <link rel="preload"> per rendere l'immagine individuabile in anticipo, il Resource Load Delay è stato ridotto ad appena il 2% del tempo di LCP. Questo dimostra come una semplice correzione architetturale possa risolvere un enorme collo di bottiglia prestazionale.
• Caso 2: L'anti-pattern di loading="lazy" nel mondo reale: uno sviluppatore su Stack Overflow ha segnalato un LCP desktop con un inspiegabile ritardo di caricamento di 1430 ms nonostante una rete veloce. La causa è stata ricondotta a un plugin di ottimizzazione delle immagini che applicava erroneamente il lazy loading all'immagine LCP, sostituendo il suo attributo src con un SVG segnaposto trasparente. La soluzione definitiva consiste nel disattivare questo comportamento per l'elemento LCP, consentendogli di essere scoperto e caricato in modalità eager. Questo illustra come gli strumenti di terze parti possano inavvertitamente introdurre gravi ritardi di caricamento.
• Caso 3: Il miglioramento delle prestazioni tramite fetchpriority: il caso di studio di Google Flights fornisce una prova chiara dell'impatto di una prioritizzazione esplicita. Aggiungendo semplicemente fetchpriority="high" all'immagine di sfondo LCP della pagina, il punteggio LCP è migliorato di 700 ms, scendendo da 2,6 secondi a 1,9 secondi. Questo dimostra che anche quando una risorsa è individuabile, segnalare la sua elevata importanza al browser è un passaggio cruciale per vincere la corsa alla larghezza di banda di rete.

Ispezione di rete in Chrome DevTools: usa la scorciatoia Ctrl + Shift + I per aprire i Developer Tools di Chrome, quindi seleziona la scheda "Network" e ricarica la pagina. Osserva la sequenza di caricamento. La tua risorsa LCP dovrebbe essere uno dei primi elementi messi in coda per il download. Se rimane indietro rispetto ad altri elementi, c'è un problema di Resource Load Delay. Di seguito è riportato l'esempio di un sito in cui il Resource Load Delay non è stato ottimizzato.

Utilizza i dati di Real User Monitoring (RUM): gli strumenti di Real User Monitoring spesso registrano i dati di attribuzione dell'LCP. Con i RUM puoi visualizzare la scomposizione delle sottofasi dell'LCP (nel tempo o per pagina), ottenendo un quadro chiaro del Load Delay per gli elementi LCP sull'intero sito o per singola pagina. L'esempio seguente mostra una scomposizione globale dell'LCP insieme al relativo Load Delay.

Come migliorare il Load Delay

Un Resource Load Delay si verifica quando l'ordine e la tempistica di download delle risorse non sono ottimali. Esistono, in sostanza, due modi diretti per risolvere il problema: prioritizzare la risorsa LCP o de-prioritizzare le risorse non LCP. Esploriamo alcuni pattern comuni:

Consiglio LCP: capisci il Preload Scanner: i browser moderni utilizzano un meccanismo chiamato preload scanner, che analizza rapidamente l'HTML e mette in coda le risorse per il download. Se una risorsa non può essere messa in coda dal preload scanner, dovrà attendere il più lento DOM parser, provocando ritardi. Assicurarsi che le risorse LCP siano individuabili dal preload scanner può fare una grande differenza nella riduzione del Load Delay.

1. Ottimizza la struttura HTML

Il browser (o il preload scanner) elabora l'HTML dall'alto verso il basso, accodando le risorse nell'ordine in cui appaiono. Ciò significa che più in alto appare la risorsa LCP nell'HTML, prima viene messa in coda. Per ottimizzare questo aspetto, rimuovi o differisci le risorse non necessarie dall'inizio dell'HTML:

• Applica il lazy loading alle immagini non importanti o nascoste: a volte le immagini (ad esempio le bandiere per le versioni in altre lingue del sito o le immagini nel menu) si trovano proprio all'inizio dell'HTML del sito. Queste immagini non sono affatto importanti quanto l'elemento LCP. Applicando il lazy loading a queste immagini, esse vengono saltate dal preload scanner e messe in coda un po' più tardi durante il processo di caricamento.
• Sposta gli script non importanti in fondo alla pagina: sposta in fondo alla pagina gli script che sono del tutto irrilevanti per il caricamento iniziale, per evitare che ritardino le risorse critiche. Ad esempio, il widget di una chat. Nessuno nella storia di internet ha mai avuto inizio di chattare prima che la pagina fosse visibile!

2. Evita le immagini di sfondo

Le immagini di sfondo sono invisibili al preload scanner, il che significa che verranno sempre accodate dal molto più lento DOM parser. Per evitare questo ritardo, usa invece un normale tag <img>, combinato con la proprietà CSS object-fit: cover per imitare l'aspetto di un'immagine di sfondo. In questo modo, il preload scanner può rilevare e mettere in coda l'immagine immediatamente.

3. Usa la Fetch Priority

Aggiungi l'attributo fetchpriority="high" al tuo elemento LCP per suggerire al browser di dare priorità a questa risorsa fin dall'inizio. Normalmente, le immagini vengono caricate con una priorità predefinita bassa o media. Durante la fase di layout, il browser aggiorna gli elementi visibili ad alta priorità. Impostando fetchpriority="high", il download inizia immediatamente ad alta priorità, garantendo un LCP più rapido.

La fetchpriority è solitamente meno invasiva (e meno efficace) del preloading perché stabilisce la priorità relativa di un elemento (in questo caso l'immagine è relativamente più importante di altre immagini), ma non la rende più importante, ad esempio, dei fogli di stile o degli script non bloccanti.

<img src="hero-image.jpg" alt="Immagine hero" fetchpriority="high">

4. Implementa il preloading

Il preloading modifica l'ordine in cui il preload scanner mette in coda i file. Posiziona il tag <link rel="preload"> nella sezione head della pagina per indicare al browser di recuperare le risorse critiche, come l'immagine LCP, il prima possibile. I preload possono essere usati per precaricare risorse a cui si fa riferimento più avanti nell'HTML (e che quindi vengono accodate successivamente) o anche per precaricare risorse non ancora referenziate nell'HTML (come nel caso di alcuni slider). Per la massima efficacia si consiglia di posizionare i preload dopo i fogli di stile e prima degli script nell'head della pagina.

<link rel="preload" as="image" href="hero-image.jpg">

5. Ottimizza gli stili

I fogli di stile vengono normalmente messi in coda prima della risorsa LCP, e questo per un buon motivo. Senza i fogli di stile il browser non saprà come si presenterà la pagina e non potrà avviare la fase di rendering. Tuttavia, una dimensione eccessiva del CSS e un numero spropositato di fogli di stile competeranno con la risorsa LCP per la larghezza di banda iniziale.

6. Implementa un lazy loading efficiente

L'attributo loading può essere un'arma a doppio taglio. Usa loading="eager" (o semplicemente ometti l'attributo, poiché "eager" è il valore predefinito del browser) per la tua risorsa LCP, mentre applichi loading="lazy" per le immagini fuori schermo.

• Carica in modalità eager l'elemento LCP: se l'elemento LCP viene caricato in modalità lazy, non verrà messo in coda dal preload scanner e si caricherà molto più tardi, con un impatto negativo sulle prestazioni.
• Applica il lazy loading alle immagini nel viewport: per le immagini che si trovano nel viewport visibile ma non sono risorse LCP, usa loading="lazy" per metterle in coda per il download un po' più tardi. Questo riduce la competizione di banda con la risorsa LCP.
• Evita il caricamento di immagini fuori dallo schermo (offscreen): le immagini che non si trovano nel viewport visibile non attiveranno affatto il download, eliminando completamente la competizione per la larghezza di banda.

7. Caching del browser

La cache del browser consente di evitare le richieste di rete per le risorse che sono già state memorizzate localmente sul dispositivo dell'utente. Sebbene non velocizzi la prima visualizzazione della pagina, migliorerà i tempi di caricamento per le visualizzazioni successive e per i visitatori di ritorno. Ecco come la cache del browser aiuta con il Resource Load Delay:

• Memorizza nella cache le risorse concorrenti: sebbene la memorizzazione nella cache della risorsa LCP stessa sia un'ottima strategia, la cache del browser migliora i Resource Load Delay dell'LCP memorizzando le risorse di rete che potrebbero competere con la risorsa LCP o ritardarla, come script, fogli di stile e immagini.
• Riduci il carico del server: la memorizzazione in cache riduce il numero di richieste inviate al server, il che può migliorare le prestazioni delle altre risorse liberando larghezza di banda e riducendo i cicli della CPU del server.

8. Usa le Speculation Rules

Le Speculation Rules consentono ai browser di eseguire il prefetch o il prerendering delle pagine web in base alla navigazione prevista dell'utente. Il prefetching elimina efficacemente la sottofase Time to First Byte dell'LCP e non ha alcun impatto sul Resource Load Delay. Il prerendering esegue il rendering della pagina successiva in una scheda nascosta e scarica tutte le risorse della pagina. Questo elimina tutti i ritardi di caricamento per l'elemento LCP, come mostrato in questo esempio di scomposizione dell'LCP di una pagina con prerendering.

9. Evita il Client-Side Rendering

Next Steps: Continue Optimizing LCP

Resource Load Delay è una delle quattro fasi dell'LCP. Una volta ridotta al minimo la latenza di scoperta, continua con queste guide:

• Identificare e risolvere i problemi di LCP: la metodologia diagnostica completa per trovare e risolvere tutti i problemi di LCP.
• Ottimizzare l'immagine LCP: selezione del formato dell'immagine, immagini responsive, preloading ed errori comuni sulle immagini.
• Resource Load Duration: dopo che il browser ha scoperto la risorsa, riduci il tempo necessario per scaricarla tramite compressione, formati moderni e ottimizzazione CDN.
• Element Render Delay: dopo lo scaricamento della risorsa, assicurati che il browser possa renderizzarla immediatamente liberando il main thread.