Non combattere lo scanner di precaricamento del browser

Scopri cos'è lo scanner di precaricamento del browser, come migliora le prestazioni e come puoi evitarlo.

Un aspetto trascurato dell'ottimizzazione della velocità delle pagine riguarda la conoscenza interna del browser. I browser effettuano determinate ottimizzazioni per migliorare il rendimento in modi che noi come sviluppatori non possiamo, ma solo a patto che tali ottimizzazioni non vengano involontariamente sventate.

Un'ottimizzazione del browser interno da capire è lo scanner di precaricamento del browser. In questo post parleremo di come funziona lo scanner di precaricamento e, soprattutto, di come evitare di intralciarne la visualizzazione.

Che cos'è uno scanner di precaricamento?

Ogni browser dispone di un parser HTML principale che tokenizza il markup non elaborato e lo elabora in un modello a oggetti. Tutto questo va bene finché l'analizzatore sintattico non viene messo in pausa quando trova una risorsa di blocco, come un foglio di stile caricato con un elemento <link> oppure uno script caricato con un elemento <script> senza un attributo async o defer.

Diagramma del parser HTML.
. Fig. 1. Un diagramma di come si può bloccare l'analizzatore sintattico principale del browser. In questo caso, l'analizzatore sintattico viene eseguito in un elemento <link> per un file CSS esterno, che impedisce al browser di analizzare il resto del documento (o persino il rendering di uno di questi elementi) finché il CSS non viene scaricato e analizzato.

Nel caso dei file CSS, sia l'analisi che il rendering sono bloccati per evitare un flash di contenuti senza stile (FOUC), ovvero quando una versione senza stile di una pagina può essere visualizzata brevemente prima dell'applicazione degli stili.

La home page web.dev in stato senza stile (sinistra) e con lo stato con stili (destra).
. Fig. 2: un esempio simulato di FOUC. Sulla sinistra è visualizzata la prima pagina di web.dev senza stili. A destra è visualizzata la stessa pagina con gli stili applicati. Lo stato senza stile può apparire in un lampo se il browser non blocca il rendering durante il download e l'elaborazione di un foglio di stile.

Il browser blocca anche l'analisi e il rendering della pagina quando rileva elementi <script> senza un attributo defer o async.

Il motivo è che il browser non è in grado di sapere con certezza se un determinato script modificherà il DOM mentre l'analizzatore sintattico HTML principale sta ancora svolgendo il suo lavoro. Questo è il motivo per cui è pratica comune caricare il codice JavaScript alla fine del documento, in modo che gli effetti dell'analisi e del rendering bloccati diventino marginali.

Questi sono buoni motivi per cui il browser dovrebbe bloccare sia l'analisi che il rendering. Tuttavia, bloccare uno di questi passaggi importanti non è auspicabile, in quanto possono rallentare lo spettacolo ritardando la scoperta di altre risorse importanti. Per fortuna, i browser fanno del loro meglio per mitigare questi problemi attraverso un parser HTML secondario chiamato scanner di precaricamento.

Diagramma del parser HTML principale (a sinistra) e dello scanner di precaricamento (a destra), che è l&#39;analizzatore sintattico HTML secondario.
. Fig. 3: un diagramma che mostra il funzionamento dello scanner di precaricamento in parallelo con l'analizzatore sintattico HTML principale per caricare gli asset in modo speculativo. In questo caso, l'analizzatore sintattico HTML principale è bloccato durante il caricamento e l'elaborazione del CSS prima che possa iniziare a elaborare il markup delle immagini nell'elemento <body>, ma lo scanner di precaricamento può guardare avanti nel markup non elaborato per trovare la risorsa immagine e iniziare a caricarla prima che l'analizzatore sintattico HTML principale venga sbloccato.

Il ruolo di uno scanner di precaricamento è speculativo, ovvero esamina il markup non elaborato per trovare risorse da recuperare in modo opportunistico prima che l'analizzatore sintattico principale le rilevi.

Come capire quando funziona lo scanner di precaricamento

Lo scanner di precaricamento esiste a causa di rendering e analisi bloccati. Se questi due problemi di prestazioni non sono mai esistiti, lo scanner di precaricamento non sarebbe molto utile. La chiave per capire se una pagina web trae vantaggio dallo scanner di precaricamento dipende da questi fenomeni di blocco. Per farlo, puoi introdurre un ritardo artificiale per le richieste per scoprire dove funziona lo scanner di precaricamento.

Considera questa pagina di testo e immagini di base su cui è riportato un foglio di stile come esempio. Poiché i file CSS bloccano sia il rendering che l'analisi, introduci un ritardo artificiale di due secondi per il foglio di stile attraverso un servizio di proxy. Questo ritardo consente di vedere più facilmente nella struttura a cascata della rete in cui funziona lo scanner di precaricamento.

Il grafico a cascata di rete WebPageTest illustra un ritardo artificiale di 2 secondi imposto al foglio di stile.
. Fig. 4: un WebPageTest grafico a cascata di rete di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. Anche se il foglio di stile viene ritardato artificialmente attraverso un proxy di due secondi prima di iniziare il caricamento, l'immagine situata più avanti nel payload di markup viene rilevata dallo scanner di precaricamento.

Come puoi vedere nella struttura a cascata, lo scanner di precaricamento rileva l'elemento <img> anche quando il rendering e l'analisi dei documenti sono bloccati. Senza questa ottimizzazione, il browser non è in grado di recuperare gli elementi in modo opportunistico durante il periodo di blocco e più richieste di risorse saranno consecutive anziché in parallelo.

Scongiurato l'esempio di un giocattolo, diamo un'occhiata ad alcuni modelli reali in cui è possibile annullare lo scanner di precarico e cosa si può fare per correggerli.

async script inseriti

Supponiamo che nel tuo <head> tu abbia codice HTML che include codice JavaScript incorporato come questo:

<script>
  const scriptEl = document.createElement('script');
  scriptEl.src = '/yall.min.js';

  document.head.appendChild(scriptEl);
</script>

Gli script inseriti sono async per impostazione predefinita, quindi quando questo script viene inserito si comporterà come se fosse stato applicato l'attributo async. Ciò significa che verrà eseguita il prima possibile e non bloccherà il rendering. Ottima idea, vero? Tuttavia, se presupponi che questo <script> incorporato segua un elemento <link> che carica un file CSS esterno, otterrai un risultato non ottimale:

Questo grafico di WebPageTest mostra la scansione di precaricamento non riuscita quando viene inserito uno script.
. Fig. 5: un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. La pagina contiene un singolo foglio di stile e uno script async inserito. Lo scanner di precaricamento non è in grado di rilevare lo script durante la fase di blocco del rendering perché viene inserito nel client.

Analizziamo cosa è successo qui:

  1. Quando non supera 0 secondi, viene richiesto il documento principale.
  2. Dopo 1,4 secondi, arriva il primo byte della richiesta di navigazione.
  3. Dopo 2,0 secondi, vengono richiesti il codice CSS e l'immagine.
  4. Poiché il parser è bloccato durante il caricamento del foglio di stile e il codice JavaScript incorporato che inserisce lo script async viene dopo tale foglio di stile a 2,6 secondi, la funzionalità fornita dallo script non è disponibile il prima possibile.

Questo non è ottimale perché la richiesta per lo script viene eseguita solo al termine del download del foglio di stile. Questo ritarda l'esecuzione dello script il prima possibile. Al contrario, poiché l'elemento <img> è rilevabile nel markup fornito dal server, viene rilevato dallo scanner di precaricamento.

Che cosa succede se utilizzi un tag <script> normale con l'attributo async anziché inserire lo script nel DOM?

<script src="/yall.min.js" async></script>

Ecco il risultato:

Una struttura a cascata della rete WebPageTest che mostra in che modo uno script asincrono caricato utilizzando l&#39;elemento script HTML è ancora rilevabile dallo scanner di precaricamento del browser, anche se l&#39;analizzatore sintattico principale del browser viene bloccato durante il download e l&#39;elaborazione di un foglio di stile.
. Fig. 6: un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. La pagina contiene un singolo foglio di stile e un singolo elemento async <script>. Lo scanner di precaricamento rileva lo script durante la fase di blocco della visualizzazione e lo carica contemporaneamente al CSS.

Potresti avere la tentazione di suggerire di risolvere questi problemi utilizzando rel=preload. Questa soluzione potrebbe sicuramente funzionare, ma potrebbe comportare alcuni effetti collaterali. Dopo tutto, perché usare rel=preload per risolvere un problema che può essere evitato non inserendo un elemento <script> nel DOM?

Una struttura a cascata di WebPageTest che mostra come il suggerimento della risorsa rel=preload viene utilizzato per promuovere il rilevamento di uno script inserito asincrono, anche se in un modo che potrebbe avere effetti collaterali indesiderati.
. Fig. 7: un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. La pagina contiene un singolo foglio di stile e uno script async inserito, ma lo script async viene precaricato per garantire che venga individuato prima.

Precaricamento delle "correzioni" il problema qui, ma introduce un nuovo problema: lo script async nelle prime due demo, nonostante sia caricato in <head>, viene caricato a livello "Basso" della priorità, mentre il foglio di stile viene caricato al livello la priorità. Nell'ultima demo in cui lo script async è precaricato, il foglio di stile viene ancora caricato al livello "Più alto" ma la priorità dello script è stata promossa a "Alta".

Quando viene aumentata la priorità di una risorsa, il browser le assegna più larghezza di banda. Ciò significa che, anche se il foglio di stile ha la priorità più alta, la priorità elevata dello script potrebbe causare conflitti di larghezza di banda. Questo potrebbe dipendere dalle connessioni lente o nei casi in cui le risorse sono piuttosto grandi.

La risposta è semplice: se è necessario uno script durante l'avvio, non annullare lo scanner di precaricamento inserendolo nel DOM. Effettua esperimenti a seconda delle tue esigenze con il posizionamento dell'elemento <script> e con attributi come defer e async.

Caricamento lento con JavaScript

Il caricamento lento è un ottimo metodo per conservare i dati, che viene spesso applicato alle immagini. Tuttavia, a volte il caricamento lento viene applicato erroneamente a immagini "above the fold", per così dire.

Ciò introduce potenziali problemi di rilevabilità delle risorse per quanto riguarda lo scanner di precaricamento e può, inutilmente, ritardare il tempo necessario per scoprire un riferimento a un'immagine, scaricarla, decodificarla e presentarla. Prendiamo come esempio questo markup delle immagini:

<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

L'utilizzo di un prefisso data- è un pattern comune nei caricatori lenti basati su JavaScript. Quando l'immagine viene fatta scorrere nell'area visibile, il caricatore lento rimuove il prefisso data-, il che significa che nell'esempio precedente, data-src diventa src. Questo aggiornamento richiede al browser di recuperare la risorsa.

Questo pattern non costituisce un problema finché non viene applicato alle immagini che si trovano nell'area visibile durante l'avvio. Poiché lo scanner di precaricamento non legge l'attributo data-src come faresti con un attributo src (o srcset), il riferimento dell'immagine non è stato rilevato in precedenza. Peggio ancora, il caricamento dell'immagine viene ritardato fino a dopo il download, la compilazione e l'esecuzione del codice JavaScript del caricatore lento.

Un grafico a cascata di rete WebPageTest che mostra come un&#39;immagine con caricamento lento che si trova nell&#39;area visibile durante l&#39;avvio venga necessariamente ritardata perché lo scanner di precaricamento del browser non riesce a trovare la risorsa immagine e viene caricata solo quando viene caricato il codice JavaScript necessario per il caricamento lento. L&#39;immagine viene rilevata molto più tardi del previsto.
. Fig. 8: un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. La risorsa immagine presenta un caricamento lento inutilmente, anche se è visibile nell'area visibile durante l'avvio. In questo modo lo scanner di precaricamento viene annullato e si verifica un ritardo non necessario.

A seconda delle dimensioni dell'immagine, che possono dipendere da quelle dell'area visibile, potrebbe essere un elemento candidato per l'opzione Largest Contentful Paint (LCP). Quando lo scanner di precaricamento non è in grado di recuperare in modo speculativo la risorsa immagine in anticipo, possibilmente durante il punto in cui il foglio di stile della pagina blocca il rendering, l'LCP ne risente.

La soluzione è modificare il markup delle immagini:

<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

Questo è il pattern ottimale per le immagini che si trovano nell'area visibile durante l'avvio, poiché lo scanner di precaricamento rileva e recupera la risorsa immagine più rapidamente.

Un grafico a cascata di rete WebPageTest che mostra uno scenario di caricamento di un&#39;immagine nell&#39;area visibile durante l&#39;avvio. L&#39;immagine non viene caricata lentamente, il che significa che non dipende dallo script da caricare, il che significa che lo scanner di precaricamento può rilevarla prima.
. Fig. 9: un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. Lo scanner di precaricamento rileva la risorsa immagine prima dell'inizio del caricamento di CSS e JavaScript, consentendo al browser di iniziare a caricarla.

In questo esempio semplificato, il risultato è un miglioramento di 100 millisecondi del valore LCP in caso di connessione lenta. Potrebbe non sembrare un enorme miglioramento, ma è quando si considera che la soluzione è una rapida correzione del markup e che la maggior parte delle pagine web sono più complesse di questo insieme di esempi. Ciò significa che i candidati LCP potrebbero dover fare i conti per la larghezza di banda con molte altre risorse, per cui ottimizzazioni come questa stanno diventando sempre più importanti.

Immagini di sfondo CSS

Ricorda che lo scanner di precaricamento del browser esegue la scansione del markup. Non esegue la scansione di altri tipi di risorse, come CSS, che potrebbero comportare recuperi per le immagini a cui fa riferimento la proprietà background-image.

Come l'HTML, i browser elaborano CSS in un proprio modello a oggetti, noto come CSSOM. Se vengono rilevate risorse esterne durante la creazione del CSSOM, queste vengono richieste al momento del rilevamento, non dallo scanner di precaricamento.

Supponiamo che il candidato LCP della tua pagina sia un elemento con una proprietà background-image CSS. Ecco cosa succede quando le risorse si caricano:

Un grafico a cascata di rete WebPageTest che mostra una pagina con un candidato LCP caricato da CSS utilizzando la proprietà immagine di sfondo. Poiché l&#39;immagine candidata LCP si trova in un tipo di risorsa che lo scanner di precaricamento del browser non è in grado di esaminare, il caricamento della risorsa viene ritardato fino a quando il CSS non viene scaricato ed elaborato, ritardando il tempo di visualizzazione del candidato LCP.
. Fig. 10: un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. Il candidato LCP della pagina è un elemento con una proprietà background-image CSS (riga 3). L'immagine richiesta non inizia a recuperare finché l'analizzatore sintattico CSS non la trova.

In questo caso, lo scanner di precaricamento non viene così sconfitto dall'altro. In ogni caso, se un candidato LCP nella pagina proviene da una proprietà CSS background-image, ti consigliamo di precaricare l'immagine:

<!-- Make sure this is in the <head> below any
     stylesheets, so as not to block them from loading -->
<link rel="preload" as="image" href="lcp-image.jpg">

Il suggerimento rel=preload è limitato, ma aiuta il browser a trovare l'immagine prima di quanto farebbe altrimenti:

Un grafico a cascata di rete WebPageTest che mostra un&#39;immagine di sfondo CSS (che è la candidata LCP) che viene caricata molto prima grazie all&#39;uso di un hint rel=preload. Il tempo LCP migliora di circa 250 millisecondi.
. Fig. 11: Un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile con una connessione 3G simulata. Il candidato LCP della pagina è un elemento con una proprietà background-image CSS (riga 3). Il suggerimento rel=preload consente al browser di trovare l'immagine di circa 250 millisecondi prima che senza il suggerimento.

Con il suggerimento rel=preload, il candidato LCP viene individuato prima, il che riduce il tempo LCP. Anche se questo suggerimento aiuta a risolvere il problema, l'opzione migliore potrebbe essere valutare se la candidata LCP dell'immagine deve essere caricata da CSS. Con un tag <img> avrai un maggiore controllo sul caricamento di un'immagine appropriata per l'area visibile, consentendo al contempo allo scanner di precaricamento di individuarla.

Incorporare troppe risorse

L'incorporamento è una pratica che inserisce una risorsa all'interno del codice HTML. Puoi incorporare i fogli di stile negli elementi <style>, negli script negli elementi <script> e praticamente in qualsiasi altra risorsa utilizzando la codifica base64.

L'incorporamento delle risorse può essere più veloce del download perché non viene inviata una richiesta separata per la risorsa. È proprio nel documento e si carica all'istante. Tuttavia, ci sono gravi svantaggi:

  • Se non stai memorizzando nella cache il tuo HTML (e non puoi farlo se la risposta HTML è dinamica), le risorse incorporate non vengono mai memorizzate nella cache. Questo influisce sulle prestazioni perché le risorse in linea non sono riutilizzabili.
  • Anche se puoi memorizzare nella cache l'HTML, le risorse incorporate non vengono condivise tra i documenti. Questo riduce l'efficienza della memorizzazione nella cache rispetto ai file esterni che possono essere memorizzati nella cache e riutilizzati in un'intera origine.
  • Se inserisci troppo testo in linea, lo scanner di precaricamento non troverà più risorse in un secondo momento nel documento, perché il download dei contenuti in linea aggiuntivi richiede più tempo.

Prendi come esempio questa pagina. In determinate condizioni, il candidato LCP è l'immagine nella parte superiore della pagina e il CSS si trova in un file separato caricato da un elemento <link>. La pagina utilizza anche quattro caratteri web, che vengono richiesti come file separati dalla risorsa CSS.

Un grafico a cascata di rete di WebPageTest con un file CSS esterno a cui fanno riferimento quattro caratteri. L&#39;immagine candidata LCP viene scoperta dallo scanner di precaricamento a tempo debito.
. Fig. 12: un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. L'LCP candidato della pagina è un'immagine caricata da un elemento <img>, ma viene rilevata dallo scanner di precaricamento perché il CSS e i caratteri richiesti per il caricamento della pagina in risorse separate, il che non ritarda il funzionamento dello scanner di precaricamento.

Ora cosa succede se il CSS e tutti i caratteri sono incorporati come risorse base64?

Un grafico a cascata di rete di WebPageTest con un file CSS esterno a cui fanno riferimento quattro caratteri. Lo scanner di precaricamento subisce un notevole ritardo nel rilevamento dell&#39;immagine LCP .
. Fig. 13: un grafico a cascata di rete WebPageTest di una pagina web eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. La candidata LCP della pagina è un'immagine caricata da un elemento <img>, ma l'incorporamento del CSS e delle sue quattro risorse di carattere nella sezione "` ritarda il rilevamento dell'immagine da parte dello scanner di precaricamento fino al completamento del download delle risorse.

In questo esempio, l'impatto dell'incorporamento comporta conseguenze negative per l'LCP e per le prestazioni in generale. La versione della pagina che non esegue alcun elemento incorporato visualizza l'immagine LCP in circa 3,5 secondi. La pagina che include tutto non visualizza l'immagine LCP fino a poco più di 7 secondi.

Non si tratta solo dello scanner di precaricamento. I caratteri incorporati non sono una grande strategia perché base64 è un formato inefficiente per le risorse binarie. Un altro fattore in gioco è che le risorse per i caratteri esterni non vengono scaricate a meno che non siano ritenute necessarie dal CSSOM. Quando questi caratteri sono incorporati in base64, vengono scaricati indipendentemente dal fatto che siano necessari o meno per la pagina corrente.

Il precaricamento potrebbe migliorare le cose in questo caso? Certo. Potresti precaricare l'immagine LCP e ridurre il tempo LCP, ma l'espansione del codice HTML potenzialmente non memorizzabile nella cache con risorse incorporate ha altre conseguenze negative sul rendimento. Questo pattern influisce anche sulla metrica First Contentful Paint (FCP). Nella versione della pagina in cui i contenuti non sono incorporati, il valore FCP è di circa 2,7 secondi. Nella versione in cui tutto è in linea, il valore di FCP è di circa 5,8 secondi.

Presta molta attenzione a incorporare elementi nell'HTML, in particolare le risorse con codifica Base64. In generale, questa soluzione è sconsigliata, ad eccezione delle risorse molto piccole. In linea il meno possibile, perché troppo allinearsi gioca con il fuoco.

Markup del rendering con JavaScript lato client

Non ci sono dubbi: JavaScript influisce sicuramente sulla velocità delle pagine. Non solo gli sviluppatori dipendono da questo strumento per fornire interattività, ma c'è stata anche la tendenza a fare affidamento su questo prodotto per distribuire i contenuti stessi. Questo porta in qualche modo a una migliore esperienza degli sviluppatori; ma non sempre i vantaggi per gli sviluppatori si traducono in vantaggi per gli utenti.

Un pattern in grado di annullare lo scanner di precaricamento è il rendering del markup con JavaScript lato client:

Una struttura a cascata della rete WebPageTest che mostra una pagina di base con immagini e testo sottoposti a rendering completamente sul client in JavaScript. Poiché il markup è contenuto in JavaScript, lo scanner di precaricamento non è in grado di rilevare nessuna risorsa. Tutte le risorse vengono ulteriormente ritardate a causa della rete e del tempo di elaborazione aggiuntivi richiesti dai framework JavaScript.
. Fig. 14: un grafico a cascata di rete WebPageTest di una pagina web sottoposta a rendering client eseguito su Chrome su un dispositivo mobile tramite una connessione 3G simulata. Poiché i contenuti sono inclusi in JavaScript e si basa su un framework per il rendering, la risorsa immagine nel markup eseguito dal client è nascosta dallo scanner di precaricamento. L'esperienza di rendering equivalente del server è illustrata nella Fig. 9.

Quando i payload di markup sono contenuti e visualizzati interamente tramite JavaScript nel browser, tutte le risorse in quel markup sono effettivamente invisibili allo scanner di precaricamento. Questo ritarda il rilevamento di risorse importanti, il che influisce sicuramente sull'LCP. Nel caso di questi esempi, la richiesta dell'immagine LCP viene significativamente ritardata rispetto all'esperienza equivalente visualizzata dal server che non richiede la visualizzazione di JavaScript.

Questo aspetto è leggermente diverso dall'argomento trattato in questo articolo, ma gli effetti del markup del rendering sul client vanno ben oltre la disattivazione dello scanner di precaricamento. Ad esempio, l'introduzione di JavaScript per potenziare un'esperienza che non lo richiede comporta l'introduzione di tempi di elaborazione non necessari che possono influire sull'interazione con Next Paint (INP). Eseguire il rendering di una quantità estremamente elevata di markup sul client ha più probabilità di generare attività lunghe rispetto alla stessa quantità di markup inviata dal server. Il motivo, a parte l'ulteriore elaborazione richiesta da JavaScript, è che i browser trasmettono il markup dal server e il rendering di blocchi in modo tale che tende a limitare le attività lunghe. Il markup sottoposto a rendering dal client, invece, viene gestito come una singola attività monolitica, che potrebbe influire sull'INP di una pagina.

Il rimedio a questo scenario dipende dalla risposta a questa domanda: Esiste un motivo per cui il markup della pagina non può essere fornito dal server anziché essere visualizzato sul client? Se la risposta è "no", occorre prendere in considerazione il rendering lato server (SSR) o il markup generato in modo statico, perché aiuteranno lo scanner di precaricamento a scoprire e recuperare in modo opportuno risorse importanti in anticipo.

Se la tua pagina richiede JavaScript per collegare funzionalità ad alcune parti del markup della pagina, puoi comunque farlo con SSR, tramite JavaScript "vanilla" o con l'idratazione, per ottenere il meglio da entrambi i mondi.

Aiuta lo scanner di precaricamento

Lo scanner di precaricamento è un'ottimizzazione molto efficace del browser che aiuta le pagine a caricarsi più velocemente durante l'avvio. Evitando schemi che non permettono di rilevare in anticipo risorse importanti, non solo semplifichi lo sviluppo in autonomia, ma ne crei esperienze utente migliori che daranno risultati migliori in molte metriche, tra cui alcuni Web Vitals.

Per ricapitolare, ecco alcuni aspetti da considerare in questo post:

  • Lo scanner di precaricamento del browser è un parser HTML secondario che analizza prima di quello principale se è bloccato per rilevare opportunisticamente risorse che è in grado di recuperare prima.
  • Le risorse che non sono presenti nel markup fornito dal server nella richiesta di navigazione iniziale non possono essere rilevate dallo scanner di precaricamento. I modi in cui è possibile annullare lo scanner di precaricamento possono includere (a titolo esemplificativo):
    • Iniezione di risorse nel DOM con JavaScript, che si tratti di script, immagini, fogli di stile o qualsiasi altra cosa che sarebbe meglio nel payload iniziale di markup dal server.
    • Caricamento lento di immagini o iframe above the fold utilizzando una soluzione JavaScript.
    • Markup di rendering sul client che può contenere riferimenti a sottorisorse di documento utilizzando JavaScript.
  • Lo scanner di precaricamento esegue solo la scansione dell'HTML. Non esamina i contenuti di altre risorse, in particolare il CSS, che potrebbero includere riferimenti a risorse importanti, compresi i candidati LCP.

Se, per qualsiasi motivo, non puoi evitare un pattern che influisce negativamente sulla capacità dello scanner di precaricamento di velocizzare le prestazioni di caricamento, prendi in considerazione il suggerimento della risorsa rel=preload. Se utilizzi rel=preload, esegui delle prove negli strumenti di laboratorio per assicurarti che dia l'effetto desiderato. Infine, non precaricare troppe risorse perché, quando assegni priorità a tutto, non ci sarà nulla.

Risorse

Immagine hero da Unsplash, di Mohammad Rahmani .