Scopri cos'è lo scanner di precaricamento del browser, come migliora il rendimento e come evitare che interferisca con il tuo sito.
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 intralciarti.
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 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 è 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 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'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 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.
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.
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 aggirato e a 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à eseguito 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:
async iniettato. 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:
- Quando non supera 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 codice 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 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:
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. Dopo tutto, perché usare 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 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 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 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 è problematico finché non viene applicato alle immagini presenti nel viewport 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 viene 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.
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.
Il risultato in questo esempio semplificato è 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:
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 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">
Il suggerimento rel=preload è limitato, ma aiuta il browser a trovare l'immagine prima di quanto farebbe altrimenti:
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. 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 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'inserimento in linea delle risorse può essere più veloce del loro download perché non viene inviata una richiesta separata per la risorsa. È proprio nel documento e si carica all'istante. 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. Questo influisce sulle prestazioni perché le risorse in linea non sono riutilizzabili.
- Anche se puoi memorizzare nella cache il codice 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 aggiuntivi 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, che vengono richiesti come file separati dalla risorsa CSS.
<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?
<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.
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 include nulla esegue il rendering dell'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. 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 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 genere non è consigliabile, tranne che per risorse molto piccole. In linea il meno possibile, perché troppo allinearsi gioca con il fuoco.
Markup del rendering 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. 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:
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 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). 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, 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 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 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 la scansione solo del codice 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é se dai la priorità a tutto, non lo sarà nessuna.
Risorse
- "Script asincroni" inseriti tramite script considerata dannosa
- 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 da Unsplash, di Mohammad Rahmani .