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à delle pagine riguarda la conoscenza interna 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 persino il rendering di uno di questi elementi) finché il CSS non viene scaricato e analizzato.
Nel caso dei file CSS, il rendering è bloccato per evitare il flash di contenuti senza stile (FOUC), ovvero quando una versione senza stile di una pagina può essere visualizzata brevemente prima dell'applicazione degli 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 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. Per fortuna, i browser fanno del loro meglio per mitigare questi problemi attraverso un parser HTML secondario chiamato scanner 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'interprete 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 lo scanner di precaricamento è in funzione
Lo scanner di precaricamento esiste a causa di rendering e analisi 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.
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 sia 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 in cui funziona lo 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.
Dopo aver visto questo esempio pratico, diamo un'occhiata ad alcuni schemi 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à eseguita 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 durante il caricamento del foglio di stile e il codice JavaScript incorporato che inserisce lo script
asyncviene 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 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.
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:
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. Questa soluzione potrebbe sicuramente funzionare, 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 inserito, ma lo script async viene precaricato per garantire che venga individuato 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 dipendere dalle connessioni lente o nei casi in cui le risorse sono piuttosto grandi.
La risposta qui è 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 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 lenti 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 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 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 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 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. Ecco cosa succede durante il caricamento delle risorse:
background-image CSS (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. 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 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 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. Si trova direttamente nel documento e si carica immediatamente. Tuttavia, esistono svantaggi significativi:
- 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 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.
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 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à.
Ora 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 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.
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.
Markup del rendering con JavaScript lato client
Non ci sono dubbi: JavaScript influisce sicuramente sulla velocità delle pagine. 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ò ingannare lo scanner di precaricamento è il rendering del markup con JavaScript lato client:
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 sottoposta a rendering dal server che non richiede la visualizzazione di 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 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.
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 schemi che non permettono di rilevare in anticipo risorse importanti, non solo semplifichi lo sviluppo in autonomia, ma si crea esperienze utente migliori che daranno risultati migliori in molte metriche, tra cui alcuni Web Vitals.
Per riepilogare, ecco le seguenti informazioni da ricordare di 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 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 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 utilizzirel=preload rel=preload, esegui test negli strumenti di laboratorio per assicurarti che generi l'effetto desiderato. Infine, non precaricare troppe risorse perché, quando assegni priorità a tutto, non ci sarà nulla.
Risorse
- "Script asincroni" inseriti tramite script considerati dannosi
- In che modo il precaricabrowser 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 .