Ottimizza il ritardo di caricamento della risorsa LCP

Questa guida fa parte dell'hub Largest Contentful Paint (LCP). Il Resource Load Delay è spesso il singolo fattore che contribuisce di più a un pessimo punteggio LCP, specialmente nei siti SPA! 

Ottimizza il Resource Load Delay del LCP

Il Largest Contentful Paint (LCP) è una delle 4 di quattro sottofasi del LCP: TTFB, Resource Load Delay, Resource Load Duration e Element Render Delay. 

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

Che cos'è il Resource Load Delay?

Il Resource Load Delay è il tempo tra il TTFB e quando il browser inizia il download della risorsa LCP. In pratica un browser dovrebbe accodare una risorsa LCP (l'immagine LCP per esempio)  il prima possibile. Se non viene accodata il prima possibile, molto probabilmente è perché il browser non può scoprirla subito o non la ritiene abbastanza importante.

Un valore alto qui indica un problema architetturale (dove 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 spende per identificare che la risorsa LCP è necessaria e decidere di recuperarla.

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

Per gli elementi LCP basati su testo e renderizzati usando un font di sistema, questo Resource Load Delay è tipicamente zero perché nessuna risorsa esterna deve essere recuperata. Valori di Resource Load Delay più alti sono specifici per gli elementi LCP che dipendono da una risorsa di rete esterna come un'immagine o un file video.

Come trova l'elemento LCP un browser?

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

• Il DOM Parser (Percorso Lento): Questo è il parser principale dei browser ed è una bestia. Costruisce la pagina intera  leggendo l'HTML, i fogli di stile e interagendo con il JavaScript. Questo è il percorso lento perché può essere ritardato e bloccato da altri file in download ed esecuzione per primi, creando una catena di dipendenze che introduce ritardi.
• Il Preload Scanner (Il Percorso Veloce): Poiché il DOM Parser è (relativamente) lento i browser hanno uno scanner secondario fulmineo che scansiona la pagina molto velocemente per risorse scaricabili e non verrà bloccato  da nulla. Se trova tag <script>, <img> non-lazy o <link>. Li accoda per il download immediatamente, 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 principio: assicurare che l'URL della risorsa LCP sia scopribile il prima possibile dal preload scanner.

Questo significa 2 cose per un elemento LCP:

1. Assicurati che il preload scanner possa trovarlo usando 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 il LCP sia un problema di "dimensioni del file". Questo porta i team a concentrarsi sulla compressione dell'immagine, sui formati immagine moderni e sulle immagini responsive. È un errore. La nostra ricerca sui Core Web Vitals mostra che il singolo collo di bottiglia più grande nel LCP è il TTFB (48%) seguito dal Load delay che occupa il (24%), il Load time occupa solo il 10% seguito dal Render delay che occupa il 17%.

Ora il trucco è che il load delay è quasi completamente risolvibile mentre il TTFB esisterà sempre. Questo rende il Load delay l'elemento con il più alto potenziale di ottimizzazione.

Come rilevare il Resource Load Delay

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

Passo 1: Controlla con CrUX.

CrUX sono i field data pubblici di Google dagli utenti Chrome idonei, forniti come vista mobile di 28 giorni dei tuoi Core Web Vitals al 75esimo percentile. Ti dice se un numero è buono o cattivo ma non dice chi, cosa o perché. Poiché Google fa affidamento sui dati CrUX questa è la tua migliore fonte di verità come punto di partenza.

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

Passo 2: Analizza i field data (RUM)

Il RUM raccoglie i Core Web Vitals da tutti i tuoi utenti reali e ti dà una vista molto più specifica e dettagliata. Ti dice chi e cosa, segmentato come vuoi (e quell'informazione è oro), ma non perché.

Questo screenshot di CoreDash ti dice ad esempio quali URL soffrono di Resource Load Delay (in verde)

Passo 3: Diagnostica con DevTools

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

Guida passo-passo: abbiamo scritto un walkthrough completo di questo flusso di lavoro: Diagnosticare il LCP con il pannello Performance di Chrome DevTools. Copre il setup del throttling, la registrazione di una traccia e la lettura del valore esatto del Resource Load Delay dall'insight di breakdown del LCP.

Cause comuni e soluzioni ad alto impatto

Un alto Resource Load Delay è causato da una di queste due cose: la risorsa LCP è scoperta in ritardo, o le è data una bassa fetch priority. Ecco gli errori architetturali più comuni e le relative soluzioni.

Causa: LCP caricato via CSS

Il Problema: Il preload scanner non analizza i file CSS. Quando la tua immagine LCP è definita con un background-image nel CSS, il suo URL è invisibile a questo scanner ad alta velocità. 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 alto Resource Load Delay. Per saperne di più su questo pattern, vedi la nostra guida su differire le immagini di background.

La Soluzione: L'implementazione corretta è evitare di usare background-image per qualsiasi elemento LCP critico. Usa 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>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 scopribile il prima possibile, il che minimizza il suo load delay.

Causa: Rendering lato client e Iniezione JavaScript

Il Problema: Le applicazioni che usano framework di client-side rendering (CSR) come React o Vue spesso servono una shell HTML minima. Il contenuto vero e proprio, incluso il tag <img> del LCP, viene inserito nel DOM dal JavaScript solo dopo che pesanti bundle del framework sono scaricati, analizzati ed eseguiti. Questo processo nasconde fondamentalmente la risorsa LCP al 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'intero HTML sul server. Il browser riceve un documento completo che contiene il tag <img> e il suo attributo src, rendendo la risorsa LCP immediatamente scopribile 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 istruisce il framework ad aggiungere automaticamente il corretto <link rel="preload"> e gli attributi fetchpriority="high", assicurando che l'immagine sia scoperta e recuperata con la giusta priorità.

Causa: Uso 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 di ritardare il recupero di un'immagine fino a quando non è vicina alla viewport. Mentre questa è 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 alto Resource Load Delay.

La Soluzione: La soluzione richiede diligenza.

• Rimuovi loading="lazy" dall'immagine LCP: Qualsiasi immagine che è probabile 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, above-the-fold. Omettere completamente l'attributo loading ha lo stesso effetto.
• Verifica e configura i tool di terze parti: Devi anche verificare i tool 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 tool per escludere l'immagine LCP da questo comportamento. Questo spesso comporta la creazione di una regola di esclusione per le prime una o due immagini sulla 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 alto consumo 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. Questo consuma la 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 è nel primo blocco di dati che il browser riceve (circa 14KB), la sua scoperta è ritardata di almeno un 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>.
• Riduci la priorità delle 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.
• Differisci gli script non essenziali: Gli script per analytics, ads o widget social raramente sono 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 banda di rete con la risorsa LCP.

Prioritizzazione avanzata con le Resource Hints

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

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

<link rel="preload"> non è una hint; è una direttiva. Forza il browser a scaricare una risorsa con priorità alta, anche se non è ancora scopribile dal parser principale. Posizionarlo nell'<head> del tuo HTML è il modo più diretto per risolvere i problemi di scoperta tardiva per risorse come i font, le immagini di background CSS, o le immagini LCP situate in profondità nel DOM. Per i dettagli completi di implementazione ed esempi, vedi la nostra guida dedicata su come fare il preload dell'immagine LCP.

Meccanismo

Quando un link preload viene posizionato nell'<head> del documento HTML, il preload scanner lo identifica e accoda immediatamente la risorsa specificata per il download. Questo è ideale per risorse come i font caricati via @font-face in un foglio di stile esterno, LCP con background-image CSS (sebbene l'uso di un tag <img> sia preferito), o un'immagine LCP che è posizionata in profondità all'interno di una complessa struttura DOM.

Preload responsive

Un dettaglio di implementazione critico è richiesto quando si fa il preload delle immagini responsive. Per assicurare che il browser precarichi l'immagine della dimensione corretta per la viewport dell'utente ed eviti un costoso 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 preload 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="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

Potenziale insidia

Il preload risolve il fetch timing (Load Delay e Load Duration) ma non il paint timing. Se il main thread è bloccato da JavaScript pesante o CSS render blocking 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.

fetchpriority="high" e la Priority Queue del browser

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

Come funziona la priorità nel browser

Quando il browser scopre le risorse durante il caricamento della pagina, assegna a ognuna un livello di priorità interno. Di default, le immagini nella viewport iniziano con priorità "Low" e vengono successivamente aggiornate ad "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" aggira completamente questo processo impostando l'immagine a priorità "High" dal momento in cui viene scoperta. Questo è particolarmente impattante per le immagini LCP perché elimina il ritardo dell'aggiornamento di priorità.

preload vs. fetchpriority

Queste due hints servono scopi diversi ma complementari. Il preload influisce su quando una risorsa viene scoperta e aggiunta alla coda. La fetchpriority influisce sul suo livello di priorità una volta che è nella coda. Capire questa distinzione è critico: il preload risolve la scoperta tardiva, mentre la fetchpriority risolve la priorità bassa. Per molte immagini LCP che sono già nell'HTML, la fetchpriority da sola può essere sufficiente. Per una guida completa su come interagiscono, vedi il nostro articolo sulla prioritizzazione delle risorse.

Best practice per il LCP

Per l'immagine LCP, la strategia ottimale è usarle insieme. Primo, assicurati una scoperta precoce posizionando il tag <img> presto nell'HTML o usando il preload. Secondo, aggiungi fetchpriority="high" direttamente al tag <img> (e al link preload, se usato). Questa combinazione garantisce che la risorsa non sia solo scoperta presto ma riceva anche la priorità più alta possibile per vincere la competizione per la banda di rete contro altre risorse come i fogli di stile o i font.

Esempio:

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

Quando usare fetchpriority="low"

L'attributo fetchpriority non serve solo ad alzare la priorità. Puoi anche usare fetchpriority="low" per togliere priorità alle risorse non critiche che competono per la 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="Hero image" width="1200" height="600">

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

Impatto dimostrato

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

Ottimizzare le 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 coinvolge una DNS lookup, un handshake TCP e una negoziazione TLS, e tutti devono essere completati prima che il primo byte della risorsa possa essere scaricato. Questo tempo di setup della connessione contribuisce direttamente al Resource Load Delay per gli asset cross-origin.

Le Soluzioni

• preconnect: Questa hint istruisce il browser a eseguire l'intero setup 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, eliminando la latenza di setup. Questo è altamente efficace e raccomandato per i primi uno o due domini di terze parti più critici che servono risorse LCP.
• dns-prefetch: Questa è una hint più leggera che esegue solo la DNS lookup per un dominio. Risparmia meno tempo rispetto al preconnect ma ha un supporto più ampio nei browser ed è utile come fallback o per domini di terze parti meno critici.

Best practice di implementazione

Per assicurare la massima compatibilità, fornisci entrambe le hints. Il browser userà preconnect se supportato e farà un fallback su dns-prefetch se non lo è. L'attributo crossorigin è essenziale per le risorse recuperate usando 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 delle Resource Hints per l'ottimizzazione del LCP

Per prevenire l'uso improprio e chiarire i ruoli distinti di queste potenti hints, la seguente tabella fornisce un riassunto comparativo.

Strategie olistiche e orientate al futuro

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

Il ruolo di un CDN moderno

Un 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.

• Ridurre l'overhead di connessione: Distribuendo gli asset su una rete globale di server, un CDN posiziona i contenuti geograficamente più vicini all'utente. Questo riduce intrinsecamente il tempo di round-trip (RTT) richiesto per la DNS lookup, l'handshake TCP e la negoziazione TLS, che sono tutti componenti del tempo di setup della connessione. Per un'immagine LCP ospitata su un CDN, questo riduce direttamente il suo load delay.
• CDN di immagini: I CDN specializzati per immagini offrono un doppio vantaggio. Forniscono il vantaggio della prossimità di un CDN standard mentre automatizzano anche 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 usano HTTP/3, che usa QUIC invece di TCP. L'HTTP/3 riduce il tempo di setup della connessione e mitiga l'head-of-line blocking, portando a una consegna delle risorse complessivamente più veloce ed efficiente.

Eliminare completamente il ritardo con le Speculation Rules

La Speculation Rules API può eliminare completamente il ritardo del LCP per le navigazioni successive.

Meccanismo

Questa API permette agli sviluppatori di informare dichiarativamente il browser su quali URL un utente navigherà probabilmente in seguito. Basandosi su queste regole, il browser può scegliere di fare il prerender di una pagina target in una scheda nascosta in background prima ancora che l'utente clicchi il link.

Impatto sul LCP

Quando l'utente clicca un link a una pagina con prerender, 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 sono tutti effettivamente ridotti quasi a zero dalla prospettiva dell'utente.

Esempio di caso d'uso

Su una pagina categoria di e-commerce, le speculation rules potrebbero essere usate per fare il prerender delle pagine di dettaglio prodotto per i primi elementi nella lista. Quando un utente clicca su uno di questi prodotti, la pagina appare all'istante.

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 alto load delay fornisce un esempio drammatico. L'immagine LCP era nascosta in una catena di richieste, facendo sì che il Resource Load Delay pesasse per uno sbalorditivo 75% del tempo totale del LCP. Implementando un singolo hint <link rel="preload"> per rendere l'immagine scopribile presto, il Resource Load Delay è stato ridotto a solo il 2% del tempo del LCP. Questo mostra come una semplice correzione architetturale possa risolvere un enorme collo di bottiglia prestazionale.
• Caso 2: L'anti-pattern loading="lazy" nel mondo reale: Uno sviluppatore su Stack Overflow ha riportato un LCP desktop con uno sconcertante load delay di 1.430ms 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 placeholder SVG trasparente. La soluzione definitiva è stata disabilitare questo comportamento per l'elemento LCP, permettendogli di essere scoperto e caricato in modo eager. Questo illustra come i tool di terze parti possano inavvertitamente introdurre severi load delay.
• Caso 3: Il boost prestazionale della fetchpriority: Il case study di Google Flights fornisce una chiara prova dell'impatto della prioritizzazione esplicita. Semplicemente aggiungendo fetchpriority="high" all'immagine di background LCP della pagina, il punteggio LCP è migliorato di 700ms, scendendo da 2,6 secondi a 1,9 secondi. Questo dimostra che anche quando una risorsa è scopribile, segnalare la sua alta importanza al browser è un passo critico per vincere la gara per la banda di rete.

Ispezione di rete in Chrome DevTools: Usa la scorciatoia Ctrl + Shift + I per aprire i Developer Tools di Chrome, poi seleziona la tab "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 un esempio di un sito dove il Resource Load Delay non è stato ottimizzato.

Usa i dati Real User Monitoring (RUM): I tool di Real User Monitoring spesso registrano i dati di attribuzione del LCP. Con il RUM, puoi visualizzare il breakdown delle sottofasi del LCP (nel tempo o per pagina), dandoti un quadro chiaro del load delay per gli elementi LCP su tutto il tuo sito o per singola pagina. L'esempio qui sotto mostra un breakdown globale del LCP insieme al corrispondente load delay.

Come migliorare il Load Delay

Un Resource Load Delay si verifica quando l'ordine di download e le tempistiche delle risorse non sono ottimali. Ci sono, in sostanza, due modi diretti per risolvere questo: dare priorità alla risorsa LCP o togliere priorità alle risorse non-LCP. Esploriamo alcuni pattern comuni:

Consiglio LCP: Comprendi il preload scanner: I browser moderni usano 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à aspettare il DOM parser che è più lento, risultando in ritardi. Assicurare che le tue risorse LCP siano scopribili dal preload scanner può fare una grande differenza nel ridurre il load delay.

1. Ottimizza la struttura dell'HTML

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

• Lazy-load di immagini non importanti o nascoste: A volte le immagini (per esempio le bandiere per le versioni specifiche per lingua del tuo sito o le immagini nel menu) si trovano proprio in cima all'HTML del tuo sito. Queste immagini non sono minimamente importanti quanto l'elemento LCP. Facendo il lazy loading di queste immagini vengono saltate 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 impedire che ritardino 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 le immagini di background

Le immagini di background sono invisibili al preload scanner, il che significa che saranno 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 background. In questo modo, il preload scanner può rilevare e accodare l'immagine immediatamente.

3. Usa la Fetch Priority

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

La fetchpriority è di solito meno intrusiva (e meno efficace) del preloading perché imposta la priorità relativa di un elemento (in questo caso l'immagine è relativamente più importante delle altre immagini) ma non lo rende più importante di, ad esempio, fogli di stile o 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 istruire il browser a recuperare le risorse critiche, come l'immagine LCP, il prima possibile. I preload possono essere usati per precaricare risorse che sono referenziate più avanti nell'HTML (e quindi vengono accodate più tardi) o anche per precaricare risorse che non sono ancora referenziate nell'HTML (come con alcuni slider). Per la massima efficacia si raccomanda 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 a ragion veduta. Senza i fogli di stile il browser non saprà che aspetto avrà la pagina e non può 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 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, mentre applichi loading="lazy" per le immagini offscreen.

• Caricamento eager dell'elemento LCP: Se l'elemento LCP è caricato in lazy loading, non verrà messo in coda dal preload scanner e caricherà molto più tardi, impattando negativamente sulle prestazioni.
• Lazy loading delle immagini nella viewport: Per le immagini che sono nella viewport visibile ma non sono risorse LCP, usa loading="lazy" per accodarle per il download leggermente più tardi. Questo riduce la competizione per la banda con la risorsa LCP.
• Evita il lazy loading delle immagini offscreen: Le immagini che non sono nella viewport visibile non innescheranno affatto un download, eliminando completamente la competizione per la banda.

7. Caching del browser

Il caching del browser ti permette di saltare le richieste di rete per le risorse che sono già state salvate localmente sul dispositivo dell'utente. Sebbene non velocizzerà la prima visualizzazione della pagina, migliorerà i tempi di caricamento per le visualizzazioni successive e per i visitatori di ritorno. Ecco come il caching del browser aiuta con il Resource Load Delay:

• Metti in cache le risorse concorrenti: Mentre mettere in cache la risorsa LCP stessa è un'ottima strategia, il caching del browser migliora i Resource Load Delay del LCP memorizzando le risorse di rete che potrebbero competere con o ritardare la risorsa LCP, come script, fogli di stile e immagini.
• Riduci il carico sul server: Il caching diminuisce il numero di richieste inviate al tuo server, il che può migliorare le prestazioni delle altre risorse liberando banda e riducendo i cicli CPU del server.

8. Usa le Speculation Rules

Le Speculation Rules abilitano i browser a fare il prefetch o il prerender delle pagine web in base alla navigazione prevista dell'utente. Il prefetch elimina efficacemente la sottofase Time to First Byte del LCP e non ha 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 load delay per l'elemento LCP come mostrato in questo esempio di breakdown del LCP di una pagina prerenderizzata.

9. Evita il rendering lato client

Prossimi passi: Continua a ottimizzare il LCP

Il Resource Load Delay è una delle quattro fasi del LCP. Una volta che hai minimizzato la latenza di scoperta, continua con queste guide:

• Correggi &amp;amp; Identifica i problemi del LCP: La metodologia diagnostica completa per trovare e correggere tutti i problemi del LCP.
• Ottimizza l'immagine LCP: Selezione del formato dell'immagine, immagini responsive, preloading ed errori comuni con le immagini.
• Resource Load Duration: Dopo che il browser scopre la risorsa, riduci il tempo necessario per scaricarla tramite la compressione, i formati moderni e l'ottimizzazione del CDN.
• Element Render Delay: Dopo che la risorsa viene scaricata, assicurati che il browser possa dipingerla immediatamente liberando il main thread.