Scopri cos'è lo scanner di precaricamento del browser, in che modo migliora il rendimento e come evitare che interferisca con le tue attività.
Un aspetto trascurato dell'ottimizzazione della velocità della pagina richiede di conoscere un po' le funzionalità interne del browser. I browser eseguono determinate ottimizzazioni per migliorare le prestazioni in modi che noi, in qualità di sviluppatori, non possiamo fare, ma solo a condizione che queste ottimizzazioni non vengano sventate involontariamente.
Un'ottimizzazione interna del browser da comprendere è lo scanner di precaricamento del browser. Questo post illustra il funzionamento dello scanner di precaricamento e, soprattutto, come evitare di intralciarlo.
Che cos'è uno scanner di precaricamento?
Ogni browser ha un parser HTML principale che tokenizza il markup non elaborato e lo trasforma in un modello di oggetti. Tutto procede tranquillamente finché il parser non si mette in pausa quando trova una risorsa di blocco, ad esempio un foglio di stile caricato con un elemento <link> o uno script caricato con un elemento <script> senza un attributo async o defer.
<link> per un file CSS esterno, che impedisce al browser di analizzare il resto del documento o addirittura di visualizzarlo finché il CSS non viene scaricato e analizzato.
Nel caso dei file CSS, il rendering viene bloccato per evitare un flash di contenuti privi di stile (FOUC), ovvero quando una versione non formattata di una pagina può essere visualizzata brevemente prima che vengano applicati gli stili.
Il browser blocca anche l'analisi e la visualizzazione della pagina quando rileva elementi <script> senza un attributo defer o async.
Il motivo è che il browser non può sapere con certezza se un determinato script modificherà il DOM mentre l'interprete HTML principale sta ancora svolgendo la sua funzione. Per questo motivo, è prassi 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 sintattica sia il rendering. Tuttavia, bloccare uno di questi passaggi importanti non è auspicabile, in quanto può rallentare la pubblicazione ritardando la scoperta di altre risorse importanti. Fortunatamente, i browser fanno del loro meglio per mitigare questi problemi tramite un'analisi HTML secondaria chiamata scansione di precaricamento.
<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 HTML principale venga sbloccato.
Il ruolo di uno scanner di precaricamento è speculativo, il che significa che esamina il markup non elaborato per trovare risorse da recuperare opportunisticamente prima che il parser HTML principale le scopra.
Come capire quando lo scanner di precaricamento è in funzione
Lo scanner di precaricamento esiste a causa del rendering e dell'analisi bloccati. Se questi due problemi di prestazioni non esistessero, 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.
Prendi ad esempio questa pagina di testo e immagini di base con un foglio di stile. Poiché i file CSS bloccano sia il rendering che l'analisi, viene introdotto un ritardo artificiale di due secondi per lo stile tramite un servizio proxy. Questo ritardo consente di vedere più facilmente nella struttura a cascata della rete dove è in funzione lo scanner di precaricamento.
Come puoi vedere nella sequenza, lo scanner di precaricamento rileva l'elemento <img> anche quando il rendering e l'analisi del documento sono bloccati. Senza questa ottimizzazione, il browser non può recuperare elementi in modo opportunistico durante il periodo di blocco e le richieste di risorse sarebbero più consecutive che concorrenti.
Dopo aver visto questo esempio pratico, diamo un'occhiata ad alcuni pattern reali in cui lo scanner di precarica può essere sconfitto e a cosa si può fare per correggerli.
Script async iniettati
Supponiamo che nel tuo <head> sia presente del codice HTML che include del codice JavaScript in linea come questo:
<script>
const scriptEl = document.createElement('script');
scriptEl.src = '/yall.min.js';
document.head.appendChild(scriptEl);
</script>
Gli script iniettati sono async per impostazione predefinita, quindi quando questo script viene iniettato, si comporta come se l'attributo async fosse stato applicato. Ciò significa che verrà eseguito il prima possibile e non bloccherà il rendering. Sembra ottimale, giusto? Tuttavia, se presumi che questo <script> in linea segua un elemento <link> che carica un file CSS esterno, otterrai un risultato non ottimale:
async iniettato. Lo scanner di precaricamento non riesce a rilevare lo script durante la fase di blocco della visualizzazione perché viene iniettato nel client.
Vediamo cosa è successo:
- A 0 secondi viene richiesto il documento principale.
- Dopo 1, 4 secondi arriva il primo byte della richiesta di navigazione.
- Dopo 2,0 secondi, vengono richiesti il CSS e l'immagine.
- Poiché il parser è bloccato nel caricamento del foglio di stile e il codice JavaScript in linea che inietta lo script
asyncviene visualizzato dopo il foglio di stile a 2,6 secondi, la funzionalità fornita dallo script non è disponibile il prima possibile.
Questo non è ottimale perché la richiesta dello script avviene solo al termine del download del foglio di stile. In questo modo, l'esecuzione dello script viene ritardata. Al contrario, poiché l'elemento <img> è rilevabile nel markup fornito dal server, viene rilevato dallo scanner di precaricamento.
Cosa succede se utilizzi un tag <script> normale con l'attributo async anziché iniettare lo script nel DOM?
<script src="/yall.min.js" async></script>
Ecco il risultato:
async <script>. Lo scanner di precaricamento rileva lo script durante la fase di blocco della visualizzazione e lo carica contemporaneamente al CSS.
Potresti essere tentato di suggerire che questi problemi potrebbero essere risolti utilizzando rel=preload. Funzionerebbe sicuramente, ma potrebbe comportare alcuni effetti collaterali. Dopotutto, perché utilizzare rel=preload per risolvere un problema che può essere evitato non iniettando un elemento <script> nel DOM?
async iniettato, ma lo script async viene precaricato per assicurarsi che venga rilevato prima.
Il precaricamento "risolve" il problema, ma ne introduce uno nuovo: lo script async nelle prime due demo, nonostante venga caricato in <head>, viene caricato con priorità "Bassa", mentre il foglio di stile viene caricato con priorità "Massima". Nell'ultima demo in cui lo script async è precaricato, il foglio di stile viene ancora caricato con priorità"Massima", ma la priorità dello script è stata promossa a "Alta".
Quando la priorità di una risorsa viene aumentata, il browser le assegna una maggiore larghezza di banda. Ciò significa che, anche se lo stile ha la priorità più alta, la priorità elevata dello script potrebbe causare contese per la larghezza di banda. Questo potrebbe essere un fattore determinante per le connessioni lente o nei casi in cui le risorse sono piuttosto grandi.
La risposta è semplice: se è necessario uno script durante l'avvio, non aggirare lo scanner di precaricamento iniettandolo nel DOM. Fai esperimenti, se necessario, con il posizionamento dell'elemento <script>, nonché con attributi come defer e async.
Caricamento lento con JavaScript
Il caricamento lento è un ottimo metodo per risparmiare dati, spesso applicato alle immagini. Tuttavia, a volte il caricamento differito viene applicato in modo errato alle immagini "above the fold", per così dire.
Ciò introduce potenziali problemi di rilevabilità delle risorse per quanto riguarda lo scanner di precaricamento e può ritardare inutilmente il tempo necessario per rilevare un riferimento a un'immagine, scaricarla, decodificarla e presentarla. Prendiamo ad esempio questo markup dell'immagine:
<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
L'utilizzo di un prefisso data- è un pattern comune nei caricatori lazy basati su JavaScript. Quando l'immagine viene visualizzata nel viewport, il caricamento 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 è problematico finché non viene applicato alle immagini presenti nel viewport durante l'avvio. Poiché lo scanner di precaricamento non legge l'attributo data-src nello stesso modo in cui legge un attributo src (o srcset), il riferimento all'immagine non viene rilevato prima. Peggio ancora, il caricamento dell'immagine viene ritardato fino a dopo il download, la compilazione e l'esecuzione del codice JavaScript del caricamento lento.
A seconda delle dimensioni dell'immagine, che possono dipendere dalle dimensioni dell'area visibile, potrebbe essere un elemento candidato per la metrica Largest Contentful Paint (LCP). Quando lo scanner di precaricamento non riesce a recuperare in modo speculativo la risorsa immagine in anticipo, ad esempio nel momento in cui i fogli di stile della pagina bloccano il rendering, il valore LCP peggiora.
La soluzione è modificare il markup dell'immagine:
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
Questo è il pattern ottimale per le immagini che si trovano nel viewport durante l'avvio, poiché lo scanner di precaricamento rileverà e recupererà la risorsa immagine più rapidamente.
Il risultato di questo esempio semplificato è un miglioramento di 100 millisecondi del tempo di caricamento della pagina su una connessione lenta. Potrebbe non sembrare un miglioramento enorme, ma lo è se si considera che la soluzione è una correzione rapida del markup e che la maggior parte delle pagine web è più complessa di questo insieme di esempi. Ciò significa che i candidati LCP potrebbero dover competere per la larghezza di banda con molte altre risorse, quindi ottimizzazioni come questa diventano 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 i CSS che potrebbero comportare il recupero di immagini a cui fa riferimento la proprietà background-image.
Come per l'HTML, i browser elaborano il CSS nel proprio modello di oggetti, noto come CSSOM. Se le risorse esterne vengono rilevate durante la costruzione del CSSOM, vengono richieste al momento del rilevamento e non dallo scanner di precaricamento.
Supponiamo che l'elemento candidato LCP della tua pagina sia un elemento con una proprietà CSS background-image. Quando le risorse vengono caricate, si verifica quanto segue:
background-image (riga 3). L'immagine richiesta non inizia a essere recuperata finché il parser CSS non la trova.
In questo caso, lo scanner di precaricamento non viene sconfitto, ma non viene utilizzato. Tuttavia, 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">
L'indicazione rel=preload è piccola, ma aiuta il browser a scoprire l'immagine prima che altrimenti farebbe:
background-image (riga 3). L'indicazione rel=preload aiuta il browser a scoprire l'immagine circa 250 millisecondi prima rispetto a un'immagine senza indicazione.
Con l'indicazione rel=preload, l'elemento candidato LCP viene rilevato prima, riducendo il tempo LCP. Sebbene questo suggerimento aiuti a risolvere il problema, l'opzione migliore potrebbe essere valutare se l'immagine candidata LCP deve essere caricata dal CSS. Con un tag <img>, avrai un maggiore controllo sul caricamento di un'immagine appropriata per l'area visibile, consentendo al programma di scansione del precaricamento di rilevarla.
Inserimento in linea di troppe risorse
L'inserimento in linea è una pratica che inserisce una risorsa all'interno del codice HTML. Puoi incorporare gli stili in elementi <style>, gli script in elementi <script> e praticamente qualsiasi altra risorsa utilizzando la codifica base64.
L'inserimento in linea delle risorse può essere più veloce del loro download perché non viene inviata una richiesta separata per la risorsa. Si trova direttamente nel documento e si carica immediatamente. Tuttavia, esistono svantaggi significativi:
- Se non memorizzi nella cache il codice HTML, cosa che non puoi fare se la risposta HTML è dinamica, le risorse incorporate non vengono mai memorizzate nella cache. Ciò influisce sul rendimento perché le risorse incorporate non sono riutilizzabili.
- Anche se puoi memorizzare nella cache il codice HTML, le risorse incorporate non vengono condivise tra i documenti. Ciò 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 troppi elementi in linea, ritardi la scoperta delle risorse da parte dello scanner di precaricamento più avanti nel documento, perché il download dei contenuti extra in linea richiede più tempo.
Prendiamo questa pagina come esempio. 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 richiesti come file separati dalla risorsa CSS.
<img>, ma viene rilevato dallo scanner di precaricamento perché il CSS e i caratteri necessari per il caricamento della pagina si trovano in risorse separate, il che non impedisce allo scanner di precaricamento di svolgere la sua attività.
Cosa succede se il CSS e tutti i caratteri sono incorporati come risorse base64?
<img>, ma l'inserimento in linea del CSS e delle sue quattro risorse di caratteri in "impedisce allo scanner di precaricamento di rilevare l'immagine finché queste risorse non sono state completamente scaricate.
L'impatto dell'inserimento in linea ha conseguenze negative per l'LCP in questo esempio e per il rendimento in generale. La versione della pagina che non inserisce nulla in linea mostra l'immagine LCP in circa 3,5 secondi. La pagina che inserisce tutto in linea non mostra l'immagine LCP fino a poco più di 7 secondi.
Non si tratta solo dello scanner di precaricamento. L'inserimento in linea dei caratteri non è una buona strategia perché base64 è un formato inefficiente per le risorse binarie. Un altro fattore in gioco è che le risorse dei caratteri esterni non vengono scaricate a meno che non siano ritenute necessarie dal CSSOM. Quando questi caratteri sono incorporati come base64, vengono scaricati indipendentemente dal fatto che siano necessari o meno per la pagina corrente.
Un precaricamento potrebbe migliorare la situazione? Certo. Potresti precaricare l'immagine LCP e ridurre il tempo LCP, ma l'aumento del codice HTML potenzialmente non memorizzabile nella cache con risorse incorporate ha altre conseguenze negative sulle prestazioni. Anche il First Contentful Paint (FCP) è interessato da questo modello. Nella versione della pagina in cui non è stato inserito nulla, il valore FCP è di circa 2,7 secondi. Nella versione in cui tutto è in linea, il tempo FCP è di circa 5,8 secondi.
Fai molta attenzione a inserire elementi in linea nell'HTML, in particolare le risorse codificate in base64. In genere non è consigliabile, tranne che per risorse molto piccole. Inserisci il minor numero possibile di elementi in linea, perché inserirne troppi è un rischio.
Rendering del markup con JavaScript lato client
Non c'è dubbio: JavaScript influisce in modo significativo sulla velocità della pagina. Non solo gli sviluppatori si basano su queste funzionalità per fornire interattività, ma c'è anche una tendenza a utilizzarle per pubblicare i contenuti stessi. In alcuni casi, questo approccio migliora l'esperienza degli sviluppatori, ma i vantaggi per gli sviluppatori non si traducono sempre in vantaggi per gli utenti.
Un pattern che può sconfiggere lo scanner di precaricamento è il rendering del markup con JavaScript lato client:
Quando i payload del markup sono contenuti e visualizzati interamente da JavaScript nel browser, tutte le risorse in quel markup sono effettivamente invisibili allo scanner di precaricamento. Ciò ritarda la scoperta di risorse importanti, il che influisce sicuramente sul LCP. In questi esempi, la richiesta dell'immagine LCP è significativamente ritardata rispetto all'esperienza equivalente con rendering lato server che non richiede JavaScript.
Questo argomento scosta un po' dall'obiettivo dell'articolo, ma gli effetti del rendering del markup sul client vanno ben oltre l'elusione dello scanner di precaricamento. Ad esempio, l'introduzione di JavaScript per potenziare un'esperienza che non lo richiede comporta tempi di elaborazione non necessari che possono influire su Interaction to Next Paint (INP). Il rendering di quantità estremamente elevate di markup sul client ha maggiori probabilità di generare attività lunghe rispetto alla stessa quantità di markup inviata dal server. Il motivo, oltre all'elaborazione aggiuntiva richiesta da JavaScript, è che i browser trasmettono il markup in streaming dal server e suddividono il rendering in modo da limitare le attività lunghe. Il markup con rendering lato client, invece, viene gestito come un'unica attività monolitica, che può influire sull'INP di una pagina.
Il rimedio per questo scenario dipende dalla risposta a questa domanda: c'è un motivo per cui il markup della pagina non può essere fornito dal server anziché essere visualizzato sul client? Se la risposta è "no", se possibile, devi prendere in considerazione il rendering lato server (SSR) o il markup generato in modo statico, in quanto aiuterà lo scanner di precaricamento a scoprire e recuperare in modo opportunistico le risorse importanti in anticipo.
Se la tua pagina ha bisogno di JavaScript per associare funzionalità ad alcune parti del markup della pagina, puoi comunque farlo con l'SSR, con JavaScript standard o con l'idratazione per ottenere il meglio da entrambi i mondi.
Aiutano lo scanner di precaricamento a aiutarti
Lo scanner di precaricamento è un'ottimizzazione del browser molto efficace che consente alle pagine di caricarsi più velocemente durante l'avvio. Evitando gli schemi che ne annullano la capacità di scoprire in anticipo le risorse importanti, non solo semplificate lo sviluppo, ma create esperienze utente migliori che generano risultati migliori in molte metriche, tra cui alcuni indicatori web.
Per riepilogare, ecco le seguenti informazioni da ricordare di questo post:
- Lo scanner di precaricamento del browser è un parser HTML secondario che esegue la scansione prima di quello principale se è bloccato per scoprire opportunisticamente le risorse che può recuperare prima.
- Le risorse non presenti nel markup fornito dal server nella richiesta di navigazione iniziale non possono essere rilevate dallo scanner di precaricamento. I modi in cui lo scanner di precarica può essere aggirato possono includere, a titolo esemplificativo:
- Iniezione di risorse nel DOM con JavaScript, ad esempio script, immagini, fogli di stile o qualsiasi altro elemento che sarebbe meglio inserire nel payload del markup iniziale del server.
- Caricamento lento di immagini o iframe in primo piano utilizzando una soluzione JavaScript.
- Rendering del markup sul client che potrebbe contenere riferimenti alle risorse secondarie del documento utilizzando JavaScript.
- Lo scanner di precaricamento esegue la scansione solo del codice HTML. Non esamina i contenuti di altre risorse, in particolare CSS, che potrebbero includere riferimenti ad asset importanti, inclusi i candidati LCP.
Se, per qualsiasi motivo, non riesci a evitare un pattern che influisce negativamente sulla capacità dello scanner di precaricamento di velocizzare le prestazioni di caricamento, valuta l'opzione di suggerimento della risorsa rel=preload. Se utilizzi rel=preload, esegui test negli strumenti di laboratorio per assicurarti che generi l'effetto desiderato. Infine, non precaricare troppe risorse, perché se dai la priorità a tutto, non lo sarà nessuna.
Risorse
- "Script asincroni" inseriti tramite script considerati dannosi
- In che modo il precaricatore del browser velocizza il caricamento delle pagine
- Precarica gli asset critici per migliorare la velocità di caricamento
- Stabilisci in anticipo le connessioni di rete per migliorare la velocità percepita della pagina
- Ottimizzazione di Largest Contentful Paint
Immagine hero di Unsplash, di Mohammad Rahmani .