Ottimizzare il LCP Resource Load Delay

Questa guida fa parte dell'hub Largest Contentful Paint (LCP). Il Resource Load Delay è spesso il singolo fattore che contribuisce maggiormente a un punteggio LCP scarso. La maggior parte dei team si concentra sulla compressione delle immagini quando il vero problema è che il browser ha trovato l'immagine troppo tardi.

Ottimizzare il LCP Resource Load Delay

Il Largest Contentful Paint (LCP) è composto da quattro fasi: TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay. Gli sforzi di sviluppo spesso si concentrano sulla riduzione della Load Duration tramite la compressione dei file, ma questo trascura il Resource Load Delay, che è frequentemente una fonte maggiore di latenza. Questo ritardo prima dell'inizio del download può aggiungere centinaia di millisecondi al tuo LCP, facendogli superare la soglia di 2,5 secondi per un giudizio 'Good'.

Un consiglio rapido: se il tuo LCP è un'immagine, sarà quasi sempre peggiore rispetto al testo. Devi monitorare i tipi di elementi LCP nei tuoi dati RUM, altrimenti stai volando alla cieca.

Definizione Precisa: L'Attesa Critica Prima del Download

Il Resource Load Delay è il tempo che intercorre tra il TTFB e il momento in cui il browser avvia il download della risorsa LCP. Non è il tempo di download; è la latenza di scoperta che si verifica prima dell'inizio del fetch. Un valore elevato qui indica un problema architettonico in cui il browser non riesce a trovare l'URL della risorsa nel payload HTML iniziale. Questo resource load delay può essere visto come il tempo che il browser impiega per identificare che la risorsa LCP è necessaria e decidere di recuperarla.

Per gli elementi LCP basati su testo e renderizzati utilizzando un font di sistema, questo resource load delay è tipicamente zero perché 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.

Il Motore della Scoperta: Preload Scanner vs. DOM Parser

Per ridurre il Resource Load Delay, devi capire come i browser scoprono le risorse. L'efficienza di questo processo di scoperta è il fattore primario che determina la latenza. I browser utilizzano due meccanismi: un percorso veloce e uno lento.

• Il Preload Scanner (Il Percorso Veloce): Questo è un parser secondario ad alta velocità che scansiona l'HTML grezzo alla ricerca di URL di risorse, come quelli nei tag <img> o <link>. Li mette immediatamente in coda per il download, prima che il CSS venga analizzato o il JavaScript venga eseguito. Questo è il percorso ottimale per qualsiasi risorsa critica.
• Il DOM Parser (Percorso Lento): Questo è il parser principale che costruisce il Document Object Model (DOM) completo e il CSS Object Model (CSSOM). Le risorse non trovate nell'HTML iniziale, come una background-image CSS o un elemento iniettato da JavaScript, vengono scoperte solo da questo parser. Questo è il percorso lento perché dipende dal download e dall'esecuzione di altri file prima, creando una catena di dipendenze che introduce un'elevata latenza.

L'intera strategia per ottimizzare il Resource Load Delay si basa su un principio: assicurarsi che l'URL della risorsa LCP sia individuabile dal preload scanner. Qualsiasi pattern che nasconda l'URL dal documento HTML iniziale costringe il browser a utilizzare il percorso di scoperta lento. Questo periodo di attesa si traduce direttamente in Resource Load Delay. Ogni ottimizzazione efficace consiste nell'architettare l'HTML in modo da posizionare la risorsa LCP sul percorso veloce. Per una guida completa alla prioritizzazione delle risorse del browser, consulta il nostro articolo sulla prioritizzazione delle risorse.

Perché il Load Delay è Importante

Un malinteso comune è che un LCP lento sia un problema di "dimensioni del file". Ciò porta i team a concentrarsi solo sulla compressione delle immagini per ridurre la Resource Load Duration. Sebbene l'ottimizzazione degli asset sia un fattore, l'analisi dei dati reali sul campo mostra che per molti siti con un LCP scarso, il Resource Load Delay è il principale collo di bottiglia delle prestazioni, non la Resource Load Duration.

I dati sul campo mostrano che il sito mediano con un punteggio LCP scarso ha un Resource Load Delay di 1,3 secondi. Si tratta di oltre la metà dell'intero budget di 2,5 secondi per un punteggio LCP 'Good', tutto consumato prima ancora che inizi il download della risorsa LCP. I dati indicano che questi siti passano quasi quattro volte più tempo ad aspettare l'inizio del download rispetto al tempo impiegato per il download stesso.

Questi dati espongono un frequente errore di direzione negli sforzi di sviluppo. I team possono passare settimane a rimuovere kilobyte dalle immagini per accorciare la Load Duration di pochi millisecondi, mentre un problema architettonico che causa un Load Delay di 1,5 secondi rimane irrisolto. L'LCP è un processo sequenziale; un ritardo in una fase iniziale non può essere recuperato ottimizzandone una successiva. Se un fetch viene ritardato di oltre un secondo, una differenza di 100ms nel tempo di download è irrilevante per il punteggio LCP finale. Le ottimizzazioni a più alto impatto comportano cambiamenti architettonici, come il miglioramento della scopribilità delle risorse, non solo la compressione degli asset. L'attenzione deve spostarsi dal rimpicciolire gli asset all'assicurarsi che vengano scoperti prima.

Come Rilevare il Resource Load Delay

Per correggere il Resource Load Delay, devi prima misurarlo accuratamente. Il flusso di lavoro professionale consiste nel definire prima il problema con i dati reali degli utenti (RUM) e solo successivamente passare a Chrome DevTools per un'analisi approfondita.

Passaggio 1: Analizzare i Dati sul Campo (RUM)

I dati sul campo, o Real User Monitoring (RUM), vengono raccolti dalle sessioni reali degli utenti. Gli strumenti RUM, come il Chrome User Experience Report (CrUX) pubblico o il mio strumento, CoreDash, rispondono alla domanda: cosa sta succedendo nel mondo reale? Uno strumento RUM completo fornirà anche una suddivisione delle sotto-parti LCP, mostrandoti il Resource Load Delay mediano tra i tuoi utenti. Questi dati convalidano l'esistenza di un problema LCP, mostrano quali URL sono interessati e rivelano gli elementi LCP comuni che i tuoi utenti stanno effettivamente visualizzando. Devi iniziare da qui per confermare che stai risolvendo un problema reale.

Passaggio 2: Diagnosticare con DevTools

Una volta che i tuoi dati RUM hanno identificato una pagina target e un elemento LCP, utilizzi Chrome DevTools per diagnosticarne la causa. L'obiettivo qui è riprodurre il problema e misurare le sotto-parti LCP per ottenere un valore preciso di Resource Load Delay. DevTools è anche il luogo in cui eseguire una Main Thread Analysis per vedere esattamente quali task sono in esecuzione e potenzialmente bloccano 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 utilizzando la scorciatoia Ctrl+Shift+I (Windows/Linux) o Cmd+Option+I (Mac).
• Vai alla scheda Performance.
• Assicurati che la casella di controllo Web Vitals sia abilitata nelle impostazioni di cattura. Questo sovrapporrà le informazioni sui Core Web Vitals al grafico delle prestazioni.
• È consigliabile testare con la limitazione della CPU (ad esempio, 4x o 6x slowdown) e della rete (ad esempio, Fast 4G o Slow 4G) per simulare le condizioni mobili del mondo reale, poiché è lì che i problemi di LCP sono più evidenti.

2. Registrare una Traccia delle Prestazioni:

• Fai clic sul pulsante "Reload" (l'icona della freccia circolare) nel pannello Performance. Chrome ricaricherà la pagina e registrerà una traccia dell'intero processo di caricamento.

3. Identificare l'Elemento LCP:

• Nel grafico a linee temporali risultante, cerca la traccia "Web Vitals".
• Individua il marker LCP. Facendo clic su di esso si evidenzierà l'elemento LCP nel viewport e verranno visualizzati i dettagli nel pannello di riepilogo in basso.

4. Analizzare la Suddivisione LCP:

• Nel pannello Summary dell'LCP, vedrai una suddivisione temporale che include il Resource Load Delay. Questo è il valore preciso che devi ottimizzare.
• Esamina la traccia "Network". Cerca la riga corrispondente alla risorsa LCP (solitamente un'immagine o un video). La distanza tra l'inizio del caricamento della pagina e l'inizio del download di questa risorsa è il tuo Resource Load Delay.

Cause Comuni e Soluzioni Strategiche

Identificare la causa radice è essenziale per selezionare l'ottimizzazione corretta. Ecco i pattern più comuni che introducono il Resource Load Delay.

Causa: Utilizzo di background-image CSS per l'LCP

Il Problema: Quando un'immagine viene caricata tramite la proprietà CSS background-image, è invisibile al preload scanner. 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 quindi applicato lo stile. Questa catena di dipendenze causa direttamente un elevato Resource Load Delay. Per saperne di più su questo pattern, consulta la nostra guida su come posporre le immagini di sfondo.

La Soluzione: L'implementazione corretta consiste nell'evitare l'uso di background-image per qualsiasi elemento LCP critico. Utilizza invece un tag <img> standard. Questo posiziona l'URL dell'immagine direttamente nell'HTML, dove il preload scanner può trovarlo immediatamente. Puoi ottenere lo stesso 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 Invece Così):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Un testo alt 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; /* Equivale 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 più presto possibile, riducendo al minimo il suo load delay.

Causa: Client-Side Rendering e Iniezione JavaScript

Il Problema: Le applicazioni che utilizzano framework per il client-side rendering (CSR) come React o Vue spesso servono una shell HTML minima. Il contenuto effettivo, incluso il tag <img> per l'LCP, viene inserito nel DOM da JavaScript solo dopo che i 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): I pattern architettonici 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 critica per le prestazioni.
• Ottimizzazioni Specifiche del Framework: I framework moderni forniscono anche ottimizzazioni integrate. Ad esempio, il componente Next.js <Image> ha una proprietà priority. Impostandola su true, si istruisce il framework ad aggiungere automaticamente i corretti attributi <link rel="preload"> e fetchpriority="high", assicurando che l'immagine venga scoperta e recuperata con la priorità corretta.

Causa: Utilizzo di loading="lazy" sull'Immagine LCP

Il Problema: Questo è 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 è vicina 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 elevato Resource Load Delay.

La Soluzione: La soluzione richiede diligenza.

• Rimuovere loading="lazy" dall'Immagine LCP: Qualsiasi immagine che probabilmente sarà 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 interamente l'attributo loading ha lo stesso effetto.
• Controllare e Configurare gli Strumenti di Terze Parti: Devi anche controllare 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. Ciò spesso comporta la creazione di una regola di esclusione per le prime una o due immagini della pagina.

Causa: Struttura HTML Subottimale e Documenti Grandi

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

La Soluzione: Ottimizzare 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 presto nel sorgente HTML (come le icone in un header), applica loading="lazy". Questo dice al preload scanner di saltarle, preservando la coda di download per l'elemento LCP.
• Differire gli Script Non Essenziali: Gli script per analytics, pubblicità o widget di social media sono raramente critici per il rendering iniziale. Sposta i loro tag <script> alla fine del <body> o usa l'attributo defer. Questo impedisce loro di bloccare il parser o di competere per la larghezza di banda con la risorsa LCP.

Prioritizzazione Avanzata con i Resource Hints

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

Forzare la Scoperta Anticipata con <link rel="preload">

<link rel="preload"> non è un suggerimento; è una direttiva. Costringe il browser a scaricare una risorsa con alta priorità, anche se non è ancora individuabile dal parser principale. Posizionarlo nel <head> del tuo HTML è il modo più diretto per risolvere i problemi di scoperta tardiva per risorse come font, background-image CSS o immagini LCP situate in profondità nel DOM. Per i dettagli completi sull'implementazione e gli esempi, consulta la nostra guida dedicata su come effettuare il preload dell'immagine LCP.

Meccanismo

Quando un link preload viene inserito nel <head> del documento HTML, il preload scanner lo identifica e mette immediatamente 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 con background-image CSS (sebbene sia preferibile usare un tag <img>) o un'immagine LCP che si trova in profondità all'interno di una struttura DOM complessa.

Preload Responsivo

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

Esempio di Preload Responsivo:

<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 alt descrittivo"
     fetchpriority="high"
     width="1200" height="675">
    

Potenziale Inconveniente

Il preloading risolve il fetch timing (Load Delay e Load Duration) ma non il paint timing. Se il thread principale è bloccato da JavaScript pesante o CSS render-blocking quando l'immagine precaricata arriva, l'immagine dovrà comunque aspettare per essere renderizzata, il che può spostare il collo di bottiglia dal Load Delay all'Element Render Delay.

fetchpriority="high" e la Coda di Priorità del Browser

L'attributo fetchpriority è un suggerimento 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à interno. Per impostazione predefinita, le immagini nel viewport iniziano con priorità "Low" e vengono successivamente aggiornate a "High" una volta che il browser completa il layout e determina che sono visibili. Questo aggiornamento richiede che il browser scarichi e analizzi prima il CSS, il che crea un ritardo. L'attributo fetchpriority="high" bypassa interamente questo processo impostando l'immagine a priorità "High" dal momento in cui viene scoperta. Ciò è particolarmente impattante per le immagini LCP perché elimina il ritardo dell'aggiornamento della priorità.

preload vs. fetchpriority

Questi due suggerimenti servent a scopi diversi ma complementari. preload influenza quando una risorsa viene scoperta e aggiunta alla coda. fetchpriority influenza il suo livello di priorità una volta che è nella coda. Capire questa distinzione è fondamentale: il preload risolve la scoperta tardiva, mentre il fetchpriority risolve la bassa prioritizzazione. Per molte immagini LCP che sono già nell'HTML, il solo fetchpriority può essere sufficiente. Per una guida completa su come questi 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. In primo luogo, assicura una scoperta anticipata posizionando il tag <img> all'inizio dell'HTML o utilizzando preload. In secondo luogo, aggiungi fetchpriority="high" direttamente al tag <img> (e al link preload, se utilizzato). Questa combinazione assicura che la risorsa non solo venga scoperta presto, ma che le venga anche data la massima priorità 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 le immagini above-the-fold che non sono l'elemento LCP (come piccole icone o avatar nell'header) e le risorse precaricate che sono necessarie ma non urgenti. Abbassando esplicitamente la priorità di queste risorse concorrenti, crei più spazio per la larghezza di banda per l'immagine LCP.

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

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

Impatto Comprovato

In un case study che ha coinvolto Google Flights, l'aggiunta di fetchpriority="high" all'immagine di sfondo LCP ha migliorato il tempo LCP da 2,6 secondi a 1,9 secondi, un miglioramento di 700ms.

Ottimizzazione delle Connessioni di Terze Parti: preconnect e dns-prefetch

Il Problema

Se la tua risorsa LCP è ospitata su un dominio di terze parti, come un CDN di immagini o un fornitore 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 che il primo byte della risorsa possa essere scaricato. Questo tempo di configurazione della connessione contribuisce direttamente al Resource Load Delay per gli asset cross-origin.

Le Soluzioni

• preconnect: Questo suggerimento istruisce il browser ad eseguire l'intera configurazione della connessione (DNS, TCP e TLS) per un'origine di terze parti specificata in background, in anticipo. Quando la risorsa viene effettivamente richiesta, la connessione è già attiva, eliminando la latenza di configurazione. Questo è altamente efficace e raccomandato per i due domini di terze parti più critici che servono risorse LCP.
• dns-prefetch: Questo è un suggerimento più leggero che esegue solo la ricerca DNS per un dominio. Risparmia meno tempo rispetto a preconnect ma ha un supporto browser più ampio ed è utile come fallback o per domini di terze parti meno critici.

Best Practice per l'Implementazione

Per garantire la massima compatibilità, fornisci entrambi i suggerimenti. Il browser utilizzerà preconnect se supportato e ripiegherà su dns-prefetch in caso contrario. L'attributo crossorigin è essenziale per le risorse recuperate utilizzando 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 LCP

Per evitare usi errati e chiarire i ruoli distinti di questi potenti suggerimenti, la seguente tabella fornisce un riepilogo comparativo.

Strategie Olistiche e Orientate al Futuro

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

Il Ruolo di un Moderno CDN

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

• Riduzione dell'Overhead di Connessione: Distribuendo gli asset su una rete globale di server, un CDN posiziona i contenuti geograficamente più vicini all'utente. Ciò riduce intrinsecamente il tempo di round-trip (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 un CDN, questo riduce direttamente il suo load delay.
• CDN di Immagini: I CDN di immagini specializzati offrono un doppio vantaggio. Forniscono il vantaggio di prossimità di un 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: Molti CDN moderni utilizzano HTTP/3, che usa QUIC invece di TCP. HTTP/3 riduce il tempo di configurazione della connessione e attenua il blocco head-of-line, portando a una consegna delle risorse più veloce ed efficiente nel complesso.

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 l'utente probabilmente visiterà in seguito. Sulla base di queste regole, il browser può scegliere di effettuare il prerendering di una pagina target 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 prerenderizzata, la navigazione è praticamente istantanea. La pagina è già stata completamente caricata e renderizzata in background. Per questa navigazione, TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay sono tutti effettivamente ridotti quasi a zero dal punto di vista dell'utente.

Esempio di Caso d'Uso

In una pagina di categoria e-commerce, le speculation rules potrebbero essere utilizzate per il prerendering delle pagine di dettaglio prodotto per i primi articoli della lista. Quando un utente fa clic su uno di questi prodotti, la pagina appare istantaneamente.

Sintesi dei Case Study: Dalla Teoria alla Pratica

Queste ottimizzazioni hanno un impatto misurabile nel mondo reale.

• Caso 1: Il Potere Trasformativo del Preloading: Un esperimento condotto da DebugBear su una pagina con un elevato ritardo di caricamento fornisce un esempio lampante. L'immagine LCP era nascosta in una catena di richieste, facendo sì che il Resource Load Delay rappresentasse uno sbalorditivo 75% del tempo LCP totale. Implementando un singolo suggerimento <link rel="preload"> per rendere l'immagine individuabile presto, il Resource Load Delay è stato ridotto a solo il 2% del tempo LCP. Ciò mostra come una semplice correzione architettonica possa risolvere un enorme collo di bottiglia delle prestazioni.
• Caso 2: L'Anti-Pattern loading="lazy" nel Mondo Reale: Uno sviluppatore su Stack Overflow ha segnalato un LCP desktop con un inspiegabile ritardo di caricamento di 1.430ms nonostante una rete veloce. La causa è stata rintracciata in un plugin di ottimizzazione delle immagini che applicava erroneamente il lazy loading all'immagine LCP sostituendo il suo attributo src con un segnaposto SVG trasparente. La soluzione definitiva è stata disabilitare questo comportamento per l'elemento LCP, consentendogli di essere scoperto e caricato in modo eager. Ciò illustra come gli strumenti di terze parti possano inavvertitamente introdurre gravi ritardi di caricamento.
• Caso 3: La Spinta Prestazionale di fetchpriority: Il case study di Google Flights fornisce prove chiare dell'impatto di una prioritizzazione esplicita. Semplicemente aggiungendo fetchpriority="high" all'immagine di sfondo LCP della pagina, il punteggio LCP è migliorato di 700ms, passando da 2,6 secondi a 1,9 secondi. Ciò dimostra che anche quando una risorsa è individuabile, segnalare la sua elevata importanza al browser è un passaggio critico per vincere la gara per la 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 è in ritardo rispetto ad altri elementi, c'è un problema di resource load delay. Di seguito è riportato un esempio di un sito in cui il resource load delay non è stato ottimizzato.

Usare i Dati di Real User Monitoring (RUM): Gli strumenti di Real User Monitoring spesso registrano dati di attribuzione LCP. Con il RUM, puoi visualizzare la suddivisione delle sotto-parti LCP (nel tempo o per pagina), offrendoti un quadro chiaro del load delay per gli elementi LCP in tutto il tuo sito o per singola pagina. L'esempio seguente mostra una suddivisione globale dell'LCP insieme al corrispondente load delay.

Come Migliorare il Load Delay

Un resource load delay si verifica quando l'ordine di download e il timing 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:

Suggerimento LCP: Comprendere il Preload Scanner: I browser moderni utilizzano un meccanismo chiamato preload scanner, che scansiona rapidamente l'HTML e mette le risorse in coda per il download. Se una risorsa non può essere messa in coda dal preload scanner, dovrà attendere il più lento DOM parser, causando ritardi. Assicurarsi che le risorse LCP siano individuabili dal preload scanner può fare una grande differenza nel ridurre il load delay.

1. Ottimizzare la Struttura HTML

Il browser (o il preload scanner) elabora l'HTML dall'alto verso il basso, mettendo in coda 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 dalla parte superiore dell'HTML:

• Effettuare il Lazy-Load di Immagini Non Importanti o Nascoste: A volte si trovano immagini (ad esempio bandiere per versioni linguistiche del sito o immagini nel menu) proprio nella parte superiore dell'HTML del tuo sito. Queste immagini non sono affatto importanti quanto l'elemento LCP. Effettuando il lazy-loading di queste immagini, esse vengono saltate dal preload scanner e messe in coda un po' più tardi durante il processo di caricamento.
• Spostare gli script non importanti in fondo alla pagina: Sposta gli script che sono assolutamente non importanti per il caricamento iniziale in fondo alla pagina per evitare che ritardino le risorse critiche. Ad esempio, un widget di chat. Nessuno nella storia di internet ha mai avuto bisogno di chattare prima che la pagina fosse visibile!

2. Evitare le Immagini di Sfondo

Le immagini di sfondo sono invisibili al preload scanner, il che significa che verranno sempre messe in coda dal DOM parser, molto più lento. Per evitare questo ritardo, usa 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. Usare Fetch Priority

Aggiungi l'attributo fetchpriority="high" al tuo elemento LCP per suggerire al browser che dovrebbe prioritizzare 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à, assicurando un LCP più veloce.

Fetchpriority è solitamente meno intrusivo (e meno efficace) del preloading perché imposta 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. Implementare il Preloading

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

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

5. Ottimizzare gli Stili

I fogli di stile vengono normalmente messi in coda prima della risorsa LCP e questo con buona ragione. Senza i fogli di stile il browser non saprebbe che aspetto avrà la pagina e non potrebbe iniziare la fase di rendering. Tuttavia, una dimensione eccessiva del CSS e un numero eccessivo di fogli di stile competeranno con la risorsa LCP per la larghezza di banda iniziale.

6. Implementare 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 default del browser) per la tua risorsa LCP, mentre applichi loading="lazy" per le immagini fuori schermo.

• Caricare in modo Eager l'Elemento LCP: Se l'elemento LCP è caricato in modo lazy, non verrà messo in coda dal preload scanner e verrà caricato molto più tardi, con un impatto negativo sulle prestazioni.
• Lazy-Load delle Immagini del 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. Ciò riduce la competizione per la larghezza di banda con la risorsa LCP.
• Evitare il Lazy Loading delle Immagini Fuori Schermo: Le immagini che non si trovano nel viewport visibile non attiveranno affatto un download, eliminando completamente la competizione per la larghezza di banda.

7. Browser Caching

Il browser caching ti consente di saltare le richieste di rete per 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 il browser caching aiuta con il resource load delay:

• Cache delle Risorse Concorrenti: Sebbene il caching della risorsa LCP stessa sia un'ottima strategia, il browser caching migliora i LCP resource load delays memorizzando le risorse di rete che potrebbero competere con la risorsa LCP o ritardarla, come script, fogli di stile e immagini.
• Ridurre il Carico del Server: Il caching riduce il numero di richieste inviate al tuo server, il che può migliorare le prestazioni di altre risorse liberando larghezza di banda e riducendo i cicli della CPU del server.

8. Usare le Speculation Rules

Le Speculation Rules consentono ai browser di pre-recuperare o pre-renderizzare le pagine web sulla base della navigazione prevista dell'utente. Il pre-recupero elimina efficacemente la sotto-parte Time to First Byte dell'LCP e non ha alcun impatto sul resource load delay. Il pre-rendering renderizza la pagina successiva in una scheda nascosta e scarica tutte le risorse della pagina. Ciò elimina tutti i ritardi di caricamento per l'elemento LCP, come mostrato in questo esempio di suddivisione LCP di una pagina pre-renderizzata.

9. Evitare il Client-Side Rendering

Passaggi Successivi: Continuare a Ottimizzare l'LCP

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

• Identificare e Risolvere i Problemi LCP: La metodologia diagnostica completa per trovare e risolvere tutti i problemi LCP.
• Ottimizzare l'Immagine LCP: Selezione del formato immagine, immagini responsive, preloading e comuni errori delle immagini.
• Resource Load Duration: Dopo che il browser ha scoperto la risorsa, riduci il tempo necessario per il download tramite compressione, formati moderni e ottimizzazione CDN.
• Element Render Delay: Dopo il download della risorsa, assicurati che il browser possa disegnarla immediatamente liberando il thread principale.