Risolvere "Avoid Chaining Critical Requests" in Lighthouse

Come viene determinata la priorità di download

Le richieste critiche sono le risorse scaricate con alta priorità durante il caricamento iniziale della pagina. Come viene determinata questa priorità?

La priorità di download è determinata dal browser stesso. Il browser segue una serie di regole per determinare la priorità di ogni risorsa. Quali elementi ricevono la priorità più alta dipende dalla struttura della pagina. Gli elementi che il browser ritiene necessari per il primo rendering della pagina ricevono la priorità più alta.

Il browser inizialmente fa una stima ragionata su quali elementi sono più importanti. In generale, la priorità di download funziona così: l'HTML ha sempre la priorità più alta, poi i fogli di stile, JavaScript sincrono, i font, le richieste AJAX, le immagini nella parte superiore della pagina, le immagini più in basso nella pagina e infine il JavaScript asincrono.

Puoi sovrascrivere queste priorità con l'attributo fetchpriority. Impostare fetchpriority="high" dice al browser che una risorsa è più importante di quanto avrebbe normalmente stimato. Impostare fetchpriority="low" fa l'opposto. Questo attributo ha ora il 93% di supporto browser. Per una guida completa, vedi Resource Prioritization e i Core Web Vitals.

Puoi vedere quali risorse ricevono alta priorità sulla tua pagina. Apri DevTools con Ctrl+Shift+J. Vai alla scheda Network, fai clic destro sui nomi delle colonne e seleziona 'Priority'.

Come influisce la catena di richieste critiche sul tempo di caricamento della pagina?

Quando carica una pagina, un browser inizia in modalità "blocco della visualizzazione". In questa modalità, le risorse più importanti vengono scaricate con alta priorità. Queste sono le risorse critiche.

Un browser non inizierà (completamente) a renderizzare la pagina fino a quando tutte le risorse critiche non saranno state scaricate. Quindi qualsiasi risorsa critica può bloccare il primo rendering di una pagina.

Meno risorse critiche ha una pagina, meno lavoro deve fare il browser per mostrare il primo contenuto sullo schermo, e meno competizione c'è per la CPU e le altre risorse.

Secondo il 2025 Web Almanac, solo il 15% delle pagine mobile supera l'audit delle risorse che bloccano il rendering. Ciò significa che l'85% del web ha ancora problemi di catene critiche da risolvere. Questa è una delle ragioni principali per cui solo il 55% delle origini mobile ottiene un punteggio "buono" nel First Contentful Paint. Tra i siti monitorati da CoreDash, le origini con meno di 3 richieste nella catena critica hanno un FCP mediano di 1,2 secondi, rispetto a 2,4 secondi per le origini con 8 o più richieste nella catena.

Nota: A partire da Lighthouse 13 (ottobre 2025), questo audit è stato rinominato in "Network Dependency Tree" insight. Il concetto è lo stesso: Lighthouse analizza la catena di richieste di rete ad alta priorità e segnala quando è troppo profonda.

Come risolvere "Avoid Chaining Critical Requests" in Lighthouse

Puoi ridurre l'impatto delle richieste critiche in tre modi:

1. Riduci il numero di risorse critiche. Converti le risorse critiche in risorse non critiche rimuovendole o differendole.
2. Riduci il numero di byte critici. Ridurre la dimensione delle risorse del percorso critico le fa scaricare più velocemente. La compressione Gzip o Brotli, il tree shaking di JavaScript, l'ottimizzazione delle immagini e il subsetting dei font aiutano tutti.
3. Migliora l'ordine di download del percorso critico. Usa i resource hints come il preloading per saltare la scoperta delle risorse e assicurarti che le risorse critiche vengano scaricate il più velocemente possibile. Usa HTTP 103 Early Hints per iniziare a precaricare le risorse prima ancora che l'HTML arrivi.

Quale opzione è migliore dipende dal tipo di file della risorsa:

1. HTML

L'HTML stesso viene sempre scaricato con la priorità più alta. La pagina fa sempre parte della catena di richieste critiche. Ecco perché la pagina stessa è la prima cosa da considerare durante l'ottimizzazione.

Caricamento ritardato dei contenuti: Molti siti di grandi dimensioni, come Google stesso, usano questa tecnica per ridurre la catena di richieste critiche. Nella pagina dei risultati di ricerca, ad esempio, parti del contenuto che non sono immediatamente necessarie vengono caricate successivamente tramite una richiesta AJAX.

Minifica: Più piccolo è sempre più veloce. Usa la minificazione HTML per rimuovere commenti, spazi e righe vuote dalla pagina.

Compressione: Comprimi il tuo HTML con Brotli o Gzip. Brotli ottiene tipicamente una compressione migliore del 15-20% rispetto a Gzip.

2. Fogli di stile

I fogli di stile nell'head della pagina sono sempre critici. Senza stili, un browser non sa come apparirà la pagina. I fogli di stile sono quindi una parte standard della catena di richieste critiche.

Critical CSS: Il modo più efficace per spezzare la catena CSS è incorporare il tuo critical CSS direttamente in un tag <style> nell'<head>. Questo elimina completamente la richiesta di rete che blocca il rendering. Puoi generare il critical CSS attraverso strumenti NodeJS o attraverso il Critical CSS Generator. Posiziona il critical CSS inline e carica il resto con una priorità inferiore:

<link rel="preload"
      href="css.css"
      type="text/css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet';"/>

Osserva come succede qualcosa di strano sulla pagina. Prima la pagina viene mostrata senza stili, e solo dopo il caricamento del CSS lo stile viene applicato. Tutto il contenuto lampeggerà da non stilizzato a stilizzato. Ecco perché serve il critical CSS: le regole CSS per la parte visibile della pagina sono incorporate inline, così la pagina appare correttamente fin da subito, e il resto del CSS si carica senza bloccare il rendering.

Evita le catene CSS @import: Se i tuoi file CSS usano @import per caricare altri file CSS, crei una catena dove il browser deve scaricare il file A prima ancora di scoprire che ha bisogno del file B. Sostituisci le istruzioni @import con tag <link> separati o concatena i file durante la fase di build. Questa è una delle cause più comuni di catene critiche inutilmente profonde.

Media query: Carica solo gli stili necessari per il tuo dispositivo. Se un visitatore è su mobile, non ha bisogno di scaricare gli stili desktop o di stampa. Usa l'attributo media per rendere i fogli di stile non bloccanti per i dispositivi che non corrispondono:

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

Il browser scarica solo i fogli di stile il cui attributo media corrisponde al dispositivo corrente con alta priorità. I fogli di stile non corrispondenti vengono scaricati con bassa priorità e non bloccano il rendering.

Minifica: Rimuovi il CSS inutilizzato. Molti siti usano librerie CSS come Bootstrap. Queste librerie sono spesso eccessivamente complete e non tutte le dichiarazioni di stile vengono utilizzate. Modifica queste librerie tramite un preprocessore CSS (come Sass) per rimuovere i gruppi di stili inutilizzati. I preprocessori inoltre minificano il tuo CSS rimuovendo tutti gli spazi e le interruzioni di riga. Vedi anche come risolvere 'remove unused CSS'.

Compressione: Comprimi i fogli di stile con compressione Brotli o Gzip.

3. JavaScript

I file JavaScript nell'head della pagina vengono scaricati con alta priorità per impostazione predefinita e bloccano il rendering della pagina mentre vengono scaricati ed eseguiti. JavaScript è quindi una parte standard della catena di richieste critiche.

Defer e Async: Regola la priorità dei file JavaScript caricandoli in modo asincrono tramite l'attributo async o defer. Gli script async vengono scaricati in parallelo con priorità inferiore. Gli script deferred vengono anch'essi scaricati in parallelo e la loro esecuzione viene ritardata fino a dopo che l'HTML è stato analizzato. Per un confronto completo, vedi async vs defer e come influenzano i Core Web Vitals.

// blocks loading and execution
<script src="normalscript.js"></script>
// async does not block during load, but it does block during execution
<script async src="asyncscript.js"></script>
// defer does not block during loading or execution
<script defer src="deferscript.js"></script>

Per ulteriori tecniche per differire JavaScript, vedi 16 metodi per differire o pianificare JavaScript. Se hai JavaScript inutilizzato che non può essere differito, vedi come ridurre il JavaScript inutilizzato.

Code splitting e preloading: Se la pagina non consente il caricamento asincrono di JavaScript, dividi JavaScript in più file. Posiziona la parte critica durante il caricamento della pagina in un file piccolo e precaricalo. Posiziona il JavaScript non critico in un altro file e lascialo caricare deferred o async.

Minifica: Riduci il numero di byte attraverso un minificatore JavaScript. I bundler moderni come webpack, Rollup e Vite usano terser internamente per analizzare JavaScript e renderlo il più piccolo possibile.

Compressione: Riduci il numero di byte comprimendo JavaScript tramite Gzip o Brotli.

4. Web font

I web font sono solitamente gli ultimi file nella catena di richieste critiche. Questo perché i web font dipendono dalla scoperta: vengono caricati solo quando un browser scopre che sono necessari. Per questo, un browser deve prima analizzare l'HTML e cercare nel foglio di stile quale font viene utilizzato.

Preloading: Quando sai che utilizzerai un font, è più veloce precaricare questo font. Il font viene quindi scaricato il prima possibile, minimizzando l'influenza sulla catena di richieste critiche. Precarica un font aggiungendo questo codice il prima possibile nell'head della pagina:

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Strategia per i font: Ci sono molti altri modi per velocizzare il caricamento dei font. Vedi come fare il self-hosting di Google Fonts e come garantire che il testo rimanga visibile durante il caricamento dei webfont.

• Usa sempre web font in self-hosting, mai font ospitati remotamente come Google Fonts.
• Riduci la dimensione del font con il font subsetting.
• Carica i font non critici attraverso la FontFace API.
• Usa font-display: swap per evitare che i font blocchino il rendering iniziale.
• Lascia che i browser generino le proprie varianti di font attraverso la sintesi dei font.

5. Immagini

Le immagini che appaiono nel viewport visibile durante il caricamento della pagina possono anche ricevere alta priorità e interferire con il percorso critico. Quando sei sicuro che un'immagine apparirà sempre nella parte visibile del sito web, precarica questa immagine. Aggiungi fetchpriority="high" per dire al browser che è l'immagine più importante della pagina:

<link rel="preload" as="image" href="important-image.webp">

Per tutte le immagini che non sono immediatamente visibili, carica queste immagini in modo lazy. Usa loading="lazy" per ritardare il caricamento dell'immagine fino a poco prima che diventi visibile:

<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">

6. Richieste AJAX

Le richieste AJAX ricevono sempre un'alta priorità. Pertanto, rimanda le richieste AJAX fino a quando la pagina non ha terminato il rendering. Aspetta che la pagina abbia inviato l'evento "load":

window.addEventListener('load', (event)=>{
  console.log('this is a good time for an AJAX request');
});

Se non è possibile rimandare la richiesta AJAX, puoi precaricare la risorsa per renderla disponibile al browser prima.

7. Iframe

Gli iframe vengono solitamente scaricati con alta priorità. Poiché un iframe è in realtà una pagina all'interno di una pagina, un iframe può causare un ritardo significativo nei tempi di caricamento della pagina. Le risorse richieste dall'iframe possono anche essere scaricate con alta priorità e formare la propria catena di richieste critiche. L'uso degli iframe può quindi influire significativamente sui tuoi Core Web Vitals.

Puoi ritardare il caricamento di un iframe tramite l'attributo loading="lazy". Questo spesso fa una grande differenza quando l'iframe non è immediatamente visibile durante il caricamento. Per un maggiore controllo sul timing, inietta l'iframe tramite JavaScript per assicurarti che non finisca nella catena di richieste critiche. Vedi come incorporare Google Maps senza penalizzare il PageSpeed e come incorporare YouTube con Core Web Vitals perfetti per esempi di questa tecnica.

Verifica i tuoi miglioramenti

Dopo aver ottimizzato la tua catena critica, verifica il miglioramento con il Real User Monitoring. Il tuo FCP e il LCP dovrebbero entrambi migliorare. Gli strumenti lab come Lighthouse ti danno un feedback immediato, ma i dati sul campo degli utenti reali sono ciò che conta per i Core Web Vitals.