Ottimizza il Resource Load Delay dell'LCP

Questa guida fa parte della sezione Largest Contentful Paint (LCP) del nostro centro risorse sui Core Web Vitals. Il Resource Load Delay è una delle quattro fasi sequenziali dell'LCP, ed è spesso il singolo fattore che contribuisce maggiormente a un punteggio LCP scarso. Questo articolo tratta in modo approfondito cause, diagnosi e soluzioni.

Ottimizza il Resource Load Delay dell'LCP

Il Largest Contentful Paint (LCP) è composto da quattro fasi: TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay. Gli sforzi di sviluppo si concentrano spesso sulla riduzione del Load Duration tramite la compressione dei file, ma questo trascura il Resource Load Delay, che è spesso 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 essere considerato 'Buono'.

Un consiglio rapido: se il tuo LCP è un'immagine, sarà quasi sempre peggiore rispetto al testo. Devi tracciare i tipi di elementi LCP nei tuoi dati RUM, altrimenti stai navigando 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 recupero (fetch). Un valore elevato in questo caso indica un problema architetturale 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é nessuna risorsa esterna deve essere recuperata. Valori di resource load delay più elevati sono specifici per gli elementi LCP che si basano su una risorsa di rete esterna come un'immagine o un file video.

Il motore di 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 (fast path) e un percorso lento (slow path).

• Il Preload Scanner (Il percorso veloce): Si tratta di un parser secondario ad alta velocità che scansiona l'HTML non elaborato 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 che 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) e il CSS Object Model (CSSOM) completi. 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 preliminare di altri file, creando una catena di dipendenze che introduce un'alta latenza.

L'intera strategia per ottimizzare il Resource Load Delay si basa su un principio: assicurarsi che l'URL della risorsa LCP sia rilevabile dal preload scanner. Qualsiasi pattern che nasconde 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 riguarda l'architettura del tuo HTML per 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 "dimensione del file". Questo porta i team a concentrarsi solo sulla compressione delle immagini per ridurre il Resource Load Duration. Sebbene l'ottimizzazione degli asset sia un fattore, l'analisi dei dati sul campo del mondo reale mostra che per molti siti con LCP scarso, il Resource Load Delay è il principale collo di bottiglia delle prestazioni, non il 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 'Buono', 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 download stesso.

Questi dati espongono un frequente errore di direzione dello sforzo di sviluppo. I team possono passare settimane a rimuovere kilobyte dalle immagini per accorciare il Load Duration di pochi millisecondi, mentre un problema architetturale 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 ottimizzando una fase successiva. Se un recupero è ritardato di oltre un secondo, una differenza di 100 ms nel tempo di download è irrilevante per il punteggio LCP finale. Le ottimizzazioni di maggiore impatto riguardano cambiamenti architetturali, come il miglioramento della scopribilità delle risorse, non solo la compressione degli asset. L'attenzione deve spostarsi dal rendere gli asset più piccoli al garantire che vengano scoperti prima.

Come rilevare il Resource Load Delay

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

Passo 1: Analizza i dati sul campo (RUM)

I dati sul campo, o Real User Monitoring (RUM), vengono raccolti da sessioni utente effettive. 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 dell'LCP, mostrandoti il Resource Load Delay mediano tra i tuoi utenti. Questi dati convalidano l'esistenza di un problema LCP, mostrano quali URL ne sono affetti e rivelano gli elementi LCP comuni che i tuoi utenti stanno effettivamente vedendo. Devi iniziare da qui per confermare che stai risolvendo un problema reale.

Passo 2: Diagnostica con DevTools

Una volta che i tuoi dati RUM hanno identificato una pagina target e un elemento LCP, usi Chrome DevTools per diagnosticare la causa. L'obiettivo qui è riprodurre il problema e misurare le sotto-parti dell'LCP per ottenere un valore preciso di Resource Load Delay. DevTools è anche il luogo in cui esegui una Main Thread Analysis per vedere esattamente quali attività sono in esecuzione e potenzialmente bloccano il processo di rendering.

Una guida passo-passo al pannello Performance di Chrome DevTools

Il pannello Performance in Chrome DevTools è uno strumento indispensabile per sezionare l'LCP e quantificare il load delay.

1. Configurazione e impostazione:

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

2. Registrazione di un Profilo delle Prestazioni:

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

3. Analisi e Interpretazione:

• Traccia Timings: Nella vista della timeline principale, individua la traccia Timings. Vedrai un marcatore etichettato LCP. Passando il mouse sopra questo marcatore si evidenzierà l'elemento LCP corrispondente nello screenshot del viewport principale e si visualizzerà il tempo totale dell'LCP.
• Suddivisione LCP per Fase: Fai clic sul marcatore LCP nella traccia Timings. Nella scheda Summary nella parte inferiore del pannello, troverai una ripartizione dettagliata dei tempi dell'LCP. Questa ripartizione mostra esplicitamente la durata di ciascuna delle quattro sotto-parti, incluso il Load delay, misurata in millisecondi. Questo valore è la misurazione più diretta e precisa del Resource Load Delay per quel caricamento specifico della pagina.
• Main Thread Analysis: Mentre esamini la timeline, guarda la traccia Main per eventuali attività lunghe (long tasks, blocchi di attività contrassegnati da un triangolo rosso). Se queste attività lunghe si verificano dopo che la risorsa LCP ha terminato il caricamento ma prima del marcatore LCP, è probabile che stiano contribuendo all'Element Render Delay, un problema correlato ma distinto.

Cause comuni e soluzioni ad alto impatto

Un elevato Resource Load Delay è causato da due motivi: la risorsa LCP viene scoperta in ritardo o le viene assegnata una priorità di fetch 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 la tua immagine LCP è definita con una background-image CSS, il suo URL è invisibile a questo scanner ad alta velocità. Il browser può scoprire l'immagine solo dopo aver scaricato l'HTML, aver trovato il link al file CSS, aver scaricato il file CSS, aver costruito il CSSOM e quindi aver 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 differire 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 questo):

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

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

Best Practice (Fai questo invece):

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Page Title</h1>
      </div>
    </div>

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

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

Questa implementazione fornisce lo stesso risultato visivo ma rende l'immagine LCP scopribile il prima possibile, il che riduce al minimo il suo load delay.

Causa: Rendering lato client (CSR) e Iniezione JavaScript

Il Problema: Le applicazioni che utilizzano framework di rendering lato client (CSR) come React o Vue spesso forniscono una shell HTML minima. Il contenuto effettivo, incluso il tag <img> LCP, 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 dal preload scanner, creando un'alta latenza di scoperta.

La Soluzione: La soluzione più efficace è 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 rilevabile 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 <Image> di Next.js ha una proprietà priority. Impostarla su true indica al framework di aggiungere automaticamente i tag <link rel="preload"> e gli attributi fetchpriority="high" corretti, 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 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 elevato Resource Load Delay.

La Soluzione: La soluzione richiede diligenza.

• Rimuovi loading="lazy" dall'immagine LCP: Qualsiasi immagine che è probabile che sia 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 e above-the-fold. Omettere del tutto l'attributo loading ha lo stesso effetto.
• Controlla e Configura 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. Questo spesso comporta la creazione di una regola di esclusione per la prima o le prime due immagini sulla 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 larghezza di banda, come icone dell'intestazione o script di widget di chat, vengono posizionate più in alto nel <body> rispetto all'elemento LCP, vengono scoperte e messe in coda per il download per prime. Questo consuma la larghezza di banda di rete 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 blocco di dati ricevuto dal browser (circa 14 KB), la sua scoperta viene ritardata di almeno un viaggio di andata e ritorno (round trip) di rete.

La Soluzione: Ottimizza la struttura e la priorità dei contenuti all'interno dell'HTML.

• Riordina 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-prioritizza le immagini non critiche: Per le immagini non essenziali che devono apparire presto nel codice HTML (come le icone in un'intestazione), applica loading="lazy". Questo dice al preload scanner di saltarle, preservando la coda di download per l'elemento LCP.
• Differisci gli script non essenziali: Gli script per analisi, annunci 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 di rete con la risorsa LCP.

Prioritizzazione avanzata con Resource Hints

Una volta che la risorsa LCP è scopribile nell'HTML, puoi utilizzare i resource hints per fornire al browser istruzioni più esplicite su come recuperarla. Questi hints forniscono un controllo a grana fine sulla scoperta e sulla prioritizzazione.

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

<link rel="preload"> non è un suggerimento (hint); è una direttiva. Costringe il browser a scaricare una risorsa con alta priorità, anche se non è ancora rilevabile dal parser principale. Posizionarlo all'<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 posizionate in profondità nel DOM. Per dettagli completi sull'implementazione e pratiche, consulta la nostra guida dedicata su come precaricare (preload) l'immagine LCP.

Meccanismo

Quando un link di preload viene posizionato in <head> del documento HTML, il preload scanner lo identifica e accoda immediatamente 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 l'uso di un tag <img> sia preferito), o un'immagine LCP che si trova in profondità all'interno di una struttura DOM complessa.[3]

Preload reattivo (Responsive Preloading)

È richiesto un dettaglio di implementazione critico quando si precaricano immagini reattive. Per garantire che il browser precarichi l'immagine della dimensione corretta per il viewport dell'utente ed eviti un doppio download dispendioso, il tag <link rel="preload"> deve includere gli attributi imagesrcset e imagesizes che rispecchiano perfettamente gli attributi sul corrispondente tag <img>.[4]

Esempio di Preloading Reattivo:

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

Potenziale insidia

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

Approfondimento: fetchpriority="high" e la coda delle 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.[7]

Come funziona la priorità del browser

Quando il browser scopre le risorse durante il caricamento della pagina, assegna a ciascuna di esse un livello di priorità interno. Per impostazione predefinita, le immagini nel viewport iniziano a priorità "Bassa" e vengono successivamente promosse ad "Alta" una volta che il browser completa il layout e determina che sono visibili. Questo aggiornamento richiede che il browser prima scarichi e analizzi il CSS, il che crea un ritardo. L'attributo fetchpriority="high" aggira completamente questo processo impostando l'immagine a priorità "Alta" dal momento in cui viene scoperta. Questo è particolarmente impattante per le immagini LCP perché elimina il ritardo di aggiornamento della priorità.

preload vs. fetchpriority

Questi due suggerimenti hanno 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. Comprendere questa distinzione è fondamentale: il preload risolve la scoperta tardiva, mentre fetchpriority risolve la prioritizzazione bassa. Per molte immagini LCP che sono già nell'HTML, fetchpriority da solo potrebbe 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 è usarli insieme. Innanzitutto, assicurati una scoperta anticipata posizionando il tag <img> in anticipo nell'HTML o utilizzando preload. In secondo luogo, aggiungi fetchpriority="high" direttamente al tag <img> (e al link preload, se utilizzato). Questa combinazione garantisce che la risorsa non solo venga scoperta presto, ma 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.[3, 1, 7]

Esempio:

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

Quando utilizzare fetchpriority="low"

L'attributo fetchpriority non serve solo per aumentare la priorità. Puoi anche utilizzare fetchpriority="low" per de-prioritizzare le 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'intestazione) e risorse precaricate che sono necessarie ma non urgenti. Abbassando esplicitamente la priorità di queste risorse in competizione, crei più margine di larghezza di banda per l'immagine LCP.

<!-- LCP image: high priority -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image" width="1200" height="600">

<!-- Non-critical above-fold image: low priority -->
<img src="avatar.jpg" fetchpriority="low" alt="Author avatar" width="48" height="48">

Impatto dimostrato

In un caso di studio che ha coinvolto Google Flights, l'aggiunta di fetchpriority="high" all'immagine di sfondo LCP è stata fondamentale per migliorare il tempo LCP da 2,6 secondi a 1,9 secondi, un miglioramento di 700 ms.[8]

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 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 scaricare il primo byte della risorsa. Questo tempo di configurazione della connessione è un contributore diretto al Resource Load Delay per gli asset cross-origin.[9, 2, 10, 11]

Le Soluzioni

• preconnect: Questo suggerimento indica al browser di 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à calda (warm), eliminando la latenza di configurazione. Questo è altamente efficace e consigliato per i due o tre domini di terze parti più critici che servono risorse LCP.[2]
• dns-prefetch: Si tratta di un suggerimento più leggero che esegue solo la ricerca DNS per un dominio. Consente di risparmiare meno tempo rispetto a preconnect ma ha un supporto browser più ampio ed è utile come fallback o per domini di terze parti meno critici.[2, 12]

Best Practice di Implementazione

Per garantire la massima compatibilità, fornisci entrambi i suggerimenti. Il browser utilizzerà preconnect se supportato e ricadrà 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 dell'LCP

Per prevenire l'uso improprio e chiarire i ruoli distinti di questi potenti suggerimenti, la tabella seguente fornisce un riepilogo comparativo.

Strategie olistiche e orientate al futuro

Oltre ai suggerimenti mirati, decisioni architetturali più ampie e funzionalità emergenti della piattaforma web possono fornire soluzioni olistiche e potenti al 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, specialmente per le risorse LCP.

• Riduzione dell'overhead di connessione: Distribuendo gli asset su una rete globale di server, una CDN posiziona i contenuti geograficamente più vicini all'utente. Questo 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.[13, 14, 15] Per un'immagine LCP ospitata su una CDN, questo riduce direttamente il suo load delay.
• Image CDN: Le Image CDN specializzate offrono un doppio vantaggio. Forniscono il vantaggio di prossimità di una CDN standard automatizzando anche molte ottimizzazioni complesse che riducono il Resource Load Duration, come il ridimensionamento delle immagini al volo, la compressione e la conversione in formati moderni come AVIF e WebP.[9, 1]
• Protocolli Avanzati: Molte CDN moderne sfruttano protocolli di rete superiori come HTTP/3, che utilizza QUIC invece di TCP. HTTP/3 riduce il tempo di configurazione della connessione e attenua l'head-of-line blocking, portando a una consegna delle risorse più rapida ed efficiente in generale.[16]

Eliminare completamente i ritardi con le Speculation Rules

L'API Speculation Rules è una funzionalità all'avanguardia della piattaforma web che offre il potenziale per eliminare completamente il ritardo LCP per le navigazioni successive.

Meccanismo

Questa API consente agli sviluppatori di informare in modo dichiarativo il browser sugli URL a cui l'utente probabilmente navigherà in seguito. Sulla base di queste regole, il browser può scegliere di eseguire il prerender di una pagina di destinazione in una scheda in background nascosta prima ancora che l'utente faccia clic sul link.[3, 1, 16]

Impatto sull'LCP

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

Esempio di caso d'uso

In una pagina di categoria e-commerce, le speculation rules potrebbero essere utilizzate per eseguire il prerender delle pagine di dettaglio del prodotto per i primi articoli nell'elenco. Quando un utente fa clic su uno di questi prodotti, la pagina appare all'istante, offrendo un'esperienza fluida ed eccezionalmente veloce.

Sintesi di Casi Studio: Dalla Teoria alla Pratica

L'efficacia di queste strategie di ottimizzazione non è meramente teorica; è dimostrata da dati provenienti da test e scenari del mondo reale.

• Caso 1: Il potere trasformativo del Preloading: Un esperimento condotto da DebugBear su una pagina con un elevato load delay fornisce un esempio drammatico. L'immagine LCP era nascosta in una catena di richieste, facendo sì che il Resource Load Delay rappresentasse uno sbalorditivo 75% del tempo totale LCP. Implementando un singolo suggerimento <link rel="preload"> per rendere l'immagine rilevabile in anticipo, il Resource Load Delay è stato ridotto ad appena il 2% del tempo LCP.[17] Questo mostra come una semplice correzione architetturale 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 uno sconcertante load delay di 1.430 ms nonostante una rete veloce. La causa è stata rintracciata in un plugin di ottimizzazione delle immagini che applicava in modo errato il lazy loading all'immagine LCP sostituendo il suo attributo src con un segnaposto SVG trasparente. La soluzione definitiva è stata quella di disabilitare questo comportamento per l'elemento LCP, consentendogli di essere scoperto e caricato in modo eager.[18] Questo illustra come gli strumenti di terze parti possano inavvertitamente introdurre gravi ritardi di caricamento.
• Caso 3: Il boost di prestazioni di fetchpriority: Il caso di studio di Google Flights fornisce prove evidenti dell'impatto della prioritizzazione esplicita. Semplicemente aggiungendo 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.[8] Questo dimostra che anche quando una risorsa è scopribile, segnalare la sua elevata importanza al browser è un passo critico per vincere la gara per la larghezza di banda di rete.

Ispezione di rete in Chrome DevTools: Utilizza la scorciatoia Ctrl + Shift + I per aprire gli Strumenti per Sviluppatori di Chrome, quindi seleziona la scheda "Network" e ricarica la pagina. Guarda 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.

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

Come migliorare il Load Delay

Un resource load delay si verifica quando l'ordine di download e la tempistica delle risorse non sono ottimali. Esistono, in sostanza, due modi diretti per risolvere questo 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 accoda le risorse per il download. Se una risorsa non può essere accodata dal preload scanner, dovrà attendere il parser DOM più lento, con conseguenti ritardi. Assicurarsi che le risorse LCP siano rilevabili dal preload scanner può fare una grande differenza nel ridurre il 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 accodata. Per ottimizzare questo aspetto, rimuovi o differisci le risorse non necessarie dalla parte superiore dell'HTML:

• Lazy-Load di immagini non importanti o nascoste: A volte le immagini (ad esempio bandiere per versioni in lingua specifica del tuo sito o immagini nel menu) si trovano nella parte superiore dell'HTML del tuo sito. Queste immagini non sono neanche lontanamente importanti quanto l'elemento LCP. Eseguendo il lazy-load di queste immagini, vengono ignorate dal preload scanner e accodate un po' più tardi durante il processo di caricamento.
• Sposta 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. Evita Immagini di Sfondo (Background Images)

Le immagini di sfondo sono invisibili al preload scanner, il che significa che verranno sempre accodate dal parser DOM, molto più lento. Per evitare questo ritardo, utilizza 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 accodare l'immagine immediatamente.

3. Usa Fetch Priority

Aggiungi l'attributo fetchpriority="high" al tuo elemento LCP per suggerire al browser che dovrebbe dare la 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 promuove gli elementi visibili ad alta priorità. Impostando fetchpriority="high", il download inizia immediatamente ad alta priorità, garantendo un LCP più rapido.

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 rispetto alle 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="Hero Image" fetchpriority="high">

4. Implementa il Preloading

Il preloading cambia l'ordine in cui il preload scanner accoda i file. Posiziona il tag <link rel="preload"> nell'head della pagina per indicare al browser di recuperare le risorse critiche, come l'immagine LCP, il prima possibile. I preload possono essere utilizzati per precaricare risorse a cui si fa riferimento in seguito nell'HTML (e quindi vengono accodate in seguito) 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 nell'head della pagina.

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

5. Ottimizza gli Stili

I fogli di stile vengono normalmente accodati prima della risorsa LCP e questo per una buona ragione. Senza fogli di stile il browser non saprà quale aspetto avrà la pagina e non potrà avviare 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. 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 default del browser) per la tua risorsa LCP, applicando invece loading="lazy" per le immagini fuori dallo schermo.

• Eager Load dell'elemento LCP: Se l'elemento LCP è in lazy-load, non verrà accodato dal preload scanner e verrà caricato molto più tardi, incidendo negativamente sulle prestazioni.
• Lazy-Load delle 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 leggermente più tardi. Questo riduce la competizione per la larghezza di banda con la risorsa LCP.
• Evita il Lazy Loading di 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

La cache del browser ti consente di saltare le richieste di rete per risorse che sono già state memorizzate localmente sul dispositivo dell'utente. Sebbene non acceleri la prima visualizzazione della pagina, migliorerà i tempi di caricamento per le visualizzazioni di pagina successive e per i visitatori di ritorno. Ecco come il browser caching aiuta con il resource load delay:

• Cache di risorse in competizione: Sebbene la cache della risorsa LCP stessa sia un'ottima strategia, la cache del browser migliora i resource load delays dell'LCP memorizzando risorse di rete che potrebbero competere con o ritardare la risorsa LCP, come script, fogli di stile e immagini.
• Riduci il carico del server: La cache diminuisce 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 CPU del server.

8. Usa le Speculation Rules

Le Speculation Rules consentono ai browser di precaricare (prefetch) o prerenderizzare (prerender) le pagine web in base alla navigazione prevista dell'utente. Il prefetching elimina efficacemente la sotto-parte Time to First Byte dell'LCP e non ha alcun impatto sul resource load delay. Il prerendering renderizza la 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 suddivisione LCP di una pagina prerenderizzata.

9. Evita il Rendering Lato Client (CSR)

Passi successivi: Continua a ottimizzare l'LCP

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

• Risolvi e Identifica i problemi LCP: La metodologia diagnostica completa per trovare e risolvere tutti i problemi LCP.
• Ottimizza l'immagine LCP: Selezione del formato dell'immagine, immagini reattive, preloading ed errori comuni relativi alle 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 che la risorsa è stata scaricata, assicurati che il browser possa disegnarla (paint) immediatamente liberando il thread principale.