Scopri cos'è lo scanner di precaricamento del browser, come migliora le prestazioni e come puoi evitare di ostacolarlo.
Un aspetto trascurato dell'ottimizzazione della Page Speed riguarda la conoscenza degli elementi interni del browser. I browser apportano determinate ottimizzazioni per migliorare le prestazioni in modi che noi sviluppatori non possiamo, ma solo se queste ottimizzazioni non vengono ostacolate involontariamente.
Un'ottimizzazione interna del browser da comprendere è lo scanner di precaricamento del browser. Questo post spiega come funziona lo scanner di precaricamento e, soprattutto, come evitare di ostacolarlo.
Che cos'è uno scanner di precarico?
Ogni browser ha un parser HTML principale che tokenizza il markup non elaborato e lo elabora in un modello a oggetti. Tutto questo continua allegramente finché il parser non si interrompe 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 persino di eseguirne il rendering 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 priva di stile di una pagina può essere visualizzata brevemente prima che vengano applicati gli stili.
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 può sapere con certezza se un determinato script modificherà il DOM mentre il parser HTML principale è ancora in funzione. Per questo motivo, è prassi comune caricare JavaScript alla fine del documento, in modo che gli effetti del blocco dell'analisi e del rendering 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 è sconsigliabile, in quanto può ritardare la scoperta di altre risorse importanti. Fortunatamente, i browser fanno del loro meglio per mitigare questi problemi tramite un parser HTML secondario chiamato scanner di precaricamento.
<body>, ma lo scanner di precaricamento può esaminare in anticipo il markup non elaborato per trovare la risorsa immagine e iniziare a caricarla prima che il parser 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 in modo opportunistico prima che il parser HTML principale le scopra.
Come capire quando lo scanner di precaricamento è in funzione
Lo scanner di precaricamento esiste perché il rendering e l'analisi sono bloccati. Se questi due problemi di prestazioni non fossero 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.
Prendi come 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, introduci un ritardo artificiale di due secondi per il foglio di stile tramite un servizio proxy. Questo ritardo consente di vedere più facilmente nella cascata di rete dove funziona lo scanner di precaricamento.
Come puoi vedere nel grafico a cascata, lo scanner di precaricamento rileva l'elemento <img> anche se 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 un numero maggiore di richieste di risorse sarebbero consecutive anziché simultanee.
Dopo questo esempio giocattolo, diamo un'occhiata ad alcuni pattern reali in cui lo scanner di precaricamento può essere aggirato e a cosa si può fare per risolverli.
Script async inseriti
Supponiamo che nel tuo <head> ci sia codice HTML che include 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à eseguito il prima possibile e non bloccherà il rendering. Sembra ottimale, non è vero? Tuttavia, se presumi che questo <script> in linea venga dopo un elemento <link> che carica un file CSS esterno, otterrai un risultato non ottimale:
async inserito. Lo scanner di precaricamento non riesce a rilevare lo script durante la fase di blocco del rendering, perché viene inserito nel client.
Analizziamo nel dettaglio cosa è successo:
- A 0 secondi viene richiesto il documento principale.
- A 1, 4 secondi arriva il primo byte della richiesta di navigazione.
- A 2 secondi, vengono richiesti il CSS e l'immagine.
- Poiché l'analizzatore è bloccato nel caricamento del foglio di stile e il codice JavaScript incorporato che inserisce lo script
asyncviene eseguito dopo il foglio di stile a 2,6 secondi, la funzionalità fornita dallo script non è disponibile non appena potrebbe esserlo.
Questo approccio non è ottimale perché la richiesta dello script viene eseguita solo dopo il completamento del download del foglio di stile. In questo modo, l'esecuzione dello script viene ritardata il più possibile. Al contrario, poiché l'elemento <img> è rilevabile nel markup fornito dal server, viene rilevato dallo scanner di precaricamento.
Quindi, 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:
async <script>. Lo scanner di precaricamento rileva lo script durante la fase di blocco del rendering e lo carica contemporaneamente al CSS.
Potrebbe esserci la tentazione di suggerire che questi problemi potrebbero essere risolti utilizzando rel=preload. Funzionerebbe sicuramente, ma potrebbe avere alcuni effetti collaterali. Dopo tutto, perché utilizzare rel=preload per risolvere un problema che può essere evitato non inserendo un elemento <script> nel DOM?
async inserito, ma lo script async viene precaricato per garantire che venga rilevato prima.
Il precaricamento "risolve" il problema qui, ma ne introduce uno nuovo: lo script async nelle prime due demo, nonostante sia 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 comunque caricato con priorità"Massima", ma la priorità dello script è stata aumentata a "Alta".
Quando la priorità di una risorsa viene aumentata, il browser le assegna più larghezza di banda. Ciò significa che, anche se il foglio di stile ha la priorità più alta, la priorità aumentata dello script potrebbe causare contesa di larghezza di banda. Questo potrebbe essere un fattore che influisce sulle connessioni lente o nei casi in cui le risorse sono piuttosto grandi.
La risposta qui è semplice: se è necessario uno script durante l'avvio, non disattivare lo scanner di precaricamento inserendolo nel DOM. Sperimenta in base alle esigenze con il posizionamento dell'elemento <script>, nonché con attributi come defer e async.
Caricamento lento con JavaScript
Il caricamento differito è un ottimo metodo per risparmiare dati, spesso applicato alle immagini. Tuttavia, a volte il caricamento lento viene applicato in modo errato alle immagini che si trovano "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 lazy loader basati su JavaScript. Quando l'immagine viene visualizzata nella finestra, il caricamento differito 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 che si trovano nella visualizzazione 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 in precedenza. Ancora peggio, il caricamento dell'immagine viene ritardato fino a dopo il download, la compilazione e l'esecuzione di 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, possibilmente nel momento in cui i fogli di stile della pagina bloccano il rendering, l'LCP ne risente.
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 nella finestra durante l'avvio, in quanto lo scanner di precaricamento rileva e recupera la risorsa immagine più rapidamente.
Il risultato in questo esempio semplificato è un miglioramento di 100 millisecondi della metrica LCP 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 CSS, che potrebbero comportare recuperi di immagini a cui fa riferimento la proprietà background-image.
Come l'HTML, i browser elaborano il CSS nel proprio modello a oggetti, noto come CSSOM. Se vengono rilevate risorse esterne durante la costruzione di CSSOM, queste risorse vengono richieste al momento del rilevamento e non dallo scanner di precaricamento.
Supponiamo che il candidato LCP della tua pagina sia un elemento con una proprietà CSS background-image. Ecco cosa succede durante il caricamento delle risorse:
background-image (riga 3). L'immagine richiesta non viene recuperata finché il parser CSS non la trova.
In questo caso, lo scanner di precaricamento non viene tanto sconfitto quanto non coinvolto. 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">
Questo suggerimento rel=preload è piccolo, ma aiuta il browser a scoprire l'immagine prima del previsto:
background-image (riga 3). Il suggerimento rel=preload aiuta il browser a scoprire l'immagine circa 250 millisecondi prima rispetto a quando non è presente.
Con il suggerimento rel=preload, il candidato LCP viene scoperto prima, riducendo il tempo LCP. Anche se questo suggerimento aiuta 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 adatta alla finestra, consentendo al contempo allo scanner di precaricamento di rilevarla.
Incorporamento di troppe risorse
L'incorporamento è una pratica che inserisce una risorsa all'interno dell'HTML. Puoi incorporare fogli di stile negli elementi <style>, script negli elementi <script> e praticamente qualsiasi altra risorsa utilizzando la codifica base64.
L'incorporamento delle risorse può essere più veloce del download perché non viene emessa una richiesta separata per la risorsa. Si trova direttamente nel documento e viene caricato immediatamente. Tuttavia, ci sono svantaggi significativi:
- Se non memorizzi nella cache il tuo HTML (e non puoi farlo se la risposta HTML è dinamica), le risorse incorporate non vengono mai memorizzate nella cache. Ciò influisce sulle prestazioni perché le risorse incorporate non sono riutilizzabili.
- Anche se puoi memorizzare nella cache l'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 contenuti in linea, ritardi l'individuazione delle risorse da parte dello scanner di precaricamento più avanti nel documento, perché il download di questi contenuti aggiuntivi in linea richiede più tempo.
Prendi 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 web font 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 in risorse separate, il che non ritarda il lavoro dello scanner di precaricamento.
Cosa succede se il CSS e tutti i caratteri sono incorporati come risorse base64?
<img>, ma l'incorporamento del CSS e delle quattro risorse dei caratteri nel tag `` ritarda l'individuazione dell'immagine da parte dello scanner di precaricamento finché queste risorse non vengono scaricate completamente.
L'incorporamento ha conseguenze negative per LCP in questo esempio e per il rendimento in generale. La versione della pagina che non incorpora nulla visualizza l'immagine LCP in circa 3,5 secondi. La pagina che incorpora tutto non disegna l'immagine LCP fino a poco più di 7 secondi.
Qui non è in gioco solo lo scanner di precaricamento. L'incorporamento dei caratteri non è una strategia ottimale 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 vengano ritenute necessarie dal CSSOM. Quando questi caratteri vengono incorporati come base64, vengono scaricati indipendentemente dal fatto che siano necessari per la pagina corrente o meno.
Un precaricamento potrebbe migliorare la situazione? Certo. Potresti precaricare l'immagine LCP e ridurre il tempo LCP, ma l'aumento delle dimensioni dell'HTML potenzialmente non memorizzabile nella cache con risorse incorporate ha altre conseguenze negative sulle prestazioni. Anche First Contentful Paint (FCP) è interessato da questo pattern. Nella versione della pagina in cui non è presente alcun elemento in linea, l'FCP è di circa 2,7 secondi. Nella versione in cui tutto è incorporato, il tempo FCP è di circa 5,8 secondi.
Fai molta attenzione all'incorporamento di elementi nell'HTML, in particolare delle risorse con codifica in base64. In generale, non è consigliabile, tranne che per risorse molto piccole. Inserisci il minor numero possibile di elementi in linea, perché inserirne troppi è come giocare con il fuoco.
Rendering del markup con JavaScript lato client
Non ci sono dubbi: JavaScript influisce sicuramente sulla velocità della pagina. Gli sviluppatori non solo si affidano a JavaScript per fornire interattività, ma tendono anche a utilizzarlo per la pubblicazione dei contenuti. Ciò migliora l'esperienza degli sviluppatori in alcuni modi, ma i vantaggi per gli sviluppatori non si traducono sempre in vantaggi per gli utenti.
Un pattern che può impedire il funzionamento dello scanner di precaricamento è il rendering del markup con JavaScript lato client:
Quando i payload di markup sono contenuti e sottoposti a rendering interamente da JavaScript nel browser, tutte le risorse in quel markup sono effettivamente invisibili allo scanner di precaricamento. Ciò ritarda l'individuazione di risorse importanti, il che influisce sicuramente su LCP. Nel caso di questi esempi, la richiesta dell'immagine LCP viene ritardata in modo significativo rispetto all'esperienza equivalente con rendering lato server che non richiede la visualizzazione di JavaScript.
Questo argomento si discosta un po' dal focus di questo articolo, ma gli effetti del rendering del markup sul client vanno ben oltre la sconfitta dello scanner di precaricamento. Innanzitutto, l'introduzione di JavaScript per potenziare un'esperienza che non lo richiede introduce 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 più probabilità di generare attività lunghe rispetto alla stessa quantità di markup inviata dal server. Il motivo di questa limitazione, oltre all'elaborazione aggiuntiva che comporta JavaScript, è che i browser trasmettono il markup dal server e suddividono il rendering in modo da limitare le attività lunghe. Il markup sottoposto a rendering lato client, invece, viene gestito come un'unica attività monolitica, il che potrebbe influire sull'INP di una pagina.
La soluzione per 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", è consigliabile prendere in considerazione il rendering lato server (SSR) o il markup generato staticamente, ove possibile, in quanto ciò aiuterà lo scanner di precaricamento a scoprire e recuperare in modo opportunistico le risorse importanti in anticipo.
Se la tua pagina richiede JavaScript per collegare funzionalità ad alcune parti del markup della pagina, puoi comunque farlo con il rendering lato server, con JavaScript nativo o con l'idratazione per ottenere il meglio di entrambi i mondi.
Aiutare lo scanner di precaricamento
Lo scanner di precaricamento è un'ottimizzazione del browser molto efficace che aiuta le pagine a caricarsi più rapidamente all'avvio. Evitando pattern che ne impediscono la capacità di scoprire in anticipo risorse importanti, non solo semplifichi lo sviluppo, ma crei anche esperienze utente migliori che offrono risultati migliori in molte metriche, tra cui alcuni segnali web.
Per ricapitolare, ecco i punti principali 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 in modo opportunistico 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 precaricamento può essere aggirato possono includere (ma non sono limitati a):
- Inserimento di risorse nel DOM con JavaScript, che si tratti di script, immagini, fogli di stile o qualsiasi altro elemento che sarebbe meglio inserire nel payload di markup iniziale dal server.
- Caricamento differito di immagini o iframe above the fold 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 dell'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'hint di risorsa rel=preload. Se utilizzi rel=preload, esegui test negli strumenti di laboratorio per assicurarti che produca l'effetto desiderato. Infine, non precaricare troppe risorse, perché se dai la priorità a tutto, non ne darai a niente.
Risorse
- "Script asincroni" inseriti tramite script considerati dannosi
- Come il precaricamento del browser velocizza il caricamento delle pagine
- Precaricare gli asset critici per migliorare la velocità di caricamento
- Stabilire connessioni di rete in anticipo per migliorare la Page Speed percepita
- Ottimizzazione di Largest Contentful Paint
Immagine promozionale di Unsplash, di Mohammad Rahmani .