Non combattere lo scanner di precaricamento del browser

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

Jeremy Wagner

Un aspetto trascurato dell'ottimizzazione della velocità delle pagine riguarda le informazioni interne del browser. I browser effettuano determinate ottimizzazioni per migliorare le prestazioni in modi che noi sviluppatori non possiamo, ma solo a condizione che tali ottimizzazioni non vengano involontariamente ostacolate.

Un'ottimizzazione del browser interna da comprendere è lo scanner di precaricamento del browser. In questo post parleremo di come funziona lo scanner di precaricamento e, soprattutto, di come evitare che sia d'intralcio.

Che cos'è uno scanner di precaricamento?

Ogni browser dispone di un parser HTML primario che tokenizza il markup non elaborato e lo elabora in un modello a oggetti. Tutto questo funziona perfettamente fino a quando il parser non si mette in pausa quando trova una risorsa di blocco, come un foglio di stile caricato con un elemento <link> o uno script caricato con un elemento <script> senza un attributo async o defer.

Nel caso dei file CSS, sia l'analisi sia il rendering sono bloccati per evitare un lampo di contenuti senza stile (FOUC), ovvero quando una versione di una pagina senza stile 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 uno specifico script modificherà il DOM mentre l'analizzatore sintattico HTML principale continua a svolgere il proprio lavoro. È per questo che è prassi comune caricare codice JavaScript alla fine del documento, in modo che gli effetti del blocco dell'analisi e del rendering diventino marginali.

Esistono motivi validi per cui il browser dovrebbe bloccare sia l'analisi sia il rendering. Tuttavia, bloccare uno di questi passaggi importanti è indesiderabile, poiché possono bloccare il programma ritardando il rilevamento di altre risorse importanti. Fortunatamente, i browser fanno del loro meglio per mitigare questi problemi utilizzando un parser HTML secondario chiamato scanner di precaricamento.

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 HTML principale le rilevi.

Come capire quando lo scanner di precaricamento funziona

Lo scanner di precaricamento esiste a causa del blocco del rendering e dell'analisi. 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. A questo scopo, puoi introdurre un ritardo artificiale per le richieste per scoprire dove funziona lo scanner di precaricamento.

Prendiamo come esempio questa pagina di testo e immagini di base con un foglio di stile. Poiché i file CSS bloccano sia il rendering sia l'analisi, introduci un ritardo artificiale di due secondi per il foglio di stile tramite un servizio proxy. Questo ritardo semplifica la visualizzazione nella struttura a cascata della rete in cui funziona lo scanner di precaricamento.

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

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

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

Vediamo nel dettaglio cosa è successo qui:

1. A 0 secondi, viene richiesto il documento principale.
2. Dopo 1,4 secondi, arriva il primo byte della richiesta di navigazione.
3. A 2,0 secondi, vengono richiesti il 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 avviene dopo quel foglio di stile dopo 2,6 secondi, la funzionalità fornita dallo script non sarà più disponibile.

Questo non è ottimale perché la richiesta dello script si verifica solo al termine del download del foglio di stile. In questo modo, l'esecuzione dello script viene ritardata nel più breve tempo 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>

Questo è il risultato:

Potresti avere la tentazione di suggerire che questi problemi possano essere risolti utilizzando rel=preload. Questa soluzione funzionerebbe certamente, 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?

Il precaricamento "corregge" il problema in questo punto, ma introduce un nuovo problema: 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 la priorità "Massima". Nell'ultima demo in cui lo script async è precaricato, il foglio di stile è ancora caricato con la 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 il foglio di stile ha la massima priorità, la priorità aumentata dello script potrebbe causare un conflitto di larghezza di banda. Questo potrebbe essere un fattore determinante per le connessioni lente o nei casi in cui le risorse sono molto grandi.

La risposta è semplice: se è necessario uno script durante l'avvio, non annullare lo scanner di precaricamento inserendolo nel DOM. Sperimenta in base alle tue esigenze con il posizionamento dell'elemento <script>, nonché con attributi come defer e async.

Caricamento lento con JavaScript

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

Ciò introduce potenziali problemi di rilevabilità delle risorse che riguardano lo scanner di precaricamento e può ritardare inutilmente il tempo necessario per trovare un riferimento a un'immagine, scaricarla, decodificarla e presentarla. Prendiamo come 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 modello comune nei caricatori lazy basati su JavaScript. Quando l'immagine fa scorrere l'immagine all'interno dell'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 crea problemi 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 nello stesso modo in cui farebbe un attributo src (o srcset), il riferimento dell'immagine non viene rilevato in precedenza. Peggio ancora, il caricamento dell'immagine viene ritardato fino dopo che il codice JavaScript del caricatore lento scarica, compila ed esegue.

A seconda delle dimensioni dell'immagine (che potrebbero dipendere da quelle dell'area visibile), l'immagine potrebbe essere un elemento candidato per la metrica Largest Contentful Paint (LCP). Quando lo scanner di precaricamento non è in grado di recuperare in modo speculativo la risorsa immagine, probabilmente nel momento in cui i fogli di stile della pagina bloccano il rendering, l'LCP ne risente.

La soluzione consiste nel cambiare 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 nell'area visibile durante l'avvio, in quanto lo scanner di precaricamento troverà e recupererà la risorsa immagine più rapidamente.

Il risultato in questo esempio semplificato è un miglioramento di 100 millisecondi dell'LCP in caso di connessione lenta. Potrebbe non sembrare un miglioramento significativo, ma 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 analizza altri tipi di risorse, come CSS, che potrebbero includere recuperi delle immagini a cui fa riferimento la proprietà background-image.

Come il linguaggio HTML, i browser elaborano i CSS in un proprio modello a oggetti, chiamato CSSOM. Se durante la creazione del CSSOM vengono rilevate risorse esterne, queste 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à background-image CSS. Ecco cosa succede quando le risorse vengono caricate:

In questo caso, lo scanner di precaricamento non è tanto sconfitto quanto non è coinvolto. Anche se un candidato LCP nella pagina appartiene a 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 è piccolo, ma consente al browser di trovare l'immagine prima di quanto fa altrimenti:

Con il suggerimento rel=preload, il candidato LCP viene rilevato prima, riducendo il tempo LCP. Anche se il suggerimento aiuta a risolvere il problema, la soluzione migliore potrebbe essere quella di valutare se l'immagine del candidato LCP deve essere caricato da CSS. Con un tag <img>, avrai un maggiore controllo sul caricamento di un'immagine adatta all'area visibile, consentendo allo scanner di precaricamento di individuarla.

Troppe risorse incorporate

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

Le risorse incorporate possono essere più rapide rispetto al download perché per la risorsa non viene inviata una richiesta separata. È esattamente nel documento e si carica all'istante. Tuttavia, esistono svantaggi significativi:

• Se non stai memorizzando nella cache il tuo codice HTML (e non riesci a farlo se la risposta HTML è dinamica), le risorse in linea 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 in linea 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 l'allineamento è eccessivo, lo scanner di precaricamento viene ritardato in modo da rilevare le risorse nel documento in una fase successiva, poiché il download di quei contenuti aggiuntivi incorporati richiede più tempo.

Prendiamo 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.

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

L'impatto dell'incorporamento ha conseguenze negative per l'LCP in questo esempio e per le prestazioni in generale. La versione della pagina che non include alcun elemento inserisce l'immagine LCP in circa 3,5 secondi. Nella pagina che incorpora tutto non viene visualizzata l'immagine LCP per poco più di 7 secondi.

Non c'è solo lo scanner di precaricamento. L'incorporamento di caratteri non è una strategia ottimale perché base64 è un formato inefficiente per le risorse binarie. Un altro fattore da considerare è che le risorse per i caratteri esterni non vengono scaricate a meno che non sia ritenuto necessario dal CSSOM. Quando questi caratteri sono incorporati in formato base64, vengono scaricati indipendentemente dal fatto che siano necessari o meno per la pagina corrente.

Un precaricamento potrebbe migliorare le cose? 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 First Contentful Paint (FCP) è interessato da questo pattern. Nella versione della pagina in cui non è presente alcun elemento in linea, il valore FCP è di circa 2,7 secondi. Nella versione in cui tutto è allineato, il valore FCP è di circa 5,8 secondi.

Fai molta attenzione all'incorporamento di elementi in HTML, soprattutto risorse con codifica Base64. In generale questa operazione è sconsigliata, ad eccezione delle risorse molto piccole. In linea il meno possibile, perché troppo in linea è colpi di fuoco.

Rendering del markup con JavaScript lato client

Non c'è dubbio: JavaScript influisce decisamente sulla velocità della pagina. Non solo gli sviluppatori lo dipendono per fornire interattività, ma c'è anche la tendenza a farlo per fornire contenuti stessi. Questo porta a una migliore esperienza per gli sviluppatori in qualche modo, ma i vantaggi per gli sviluppatori non sempre si traducono in vantaggi per gli utenti.

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

Quando i payload di markup sono contenuti e visualizzati interamente da JavaScript nel browser, tutte le risorse nel markup sono di fatto invisibili allo scanner di precaricamento. Questo ritarda la scoperta di risorse importanti, il che influisce di sicuro sulla metrica LCP. In questi esempi, la richiesta dell'immagine LCP presenta un ritardo significativamente rispetto all'esperienza equivalente di rendering del server che non richiede la visualizzazione di JavaScript.

Questo approccio varia leggermente rispetto a questo articolo, ma gli effetti del markup del rendering sul client vanno ben oltre lo scanner di precaricamento. Ad esempio, l'introduzione di JavaScript per supportare un'esperienza che non richiede tempi di elaborazione superflui che possono influire sull'interazione con la colorazione successiva (INP).

Inoltre, 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 di questo, a parte l'ulteriore elaborazione implicata da JavaScript, è che i browser trasmettono il markup dal server e dividono il rendering in modo tale da evitare attività lunghe. Il markup sottoposto a rendering dal client, d'altra parte, è gestito come una singola attività monolitica, che potrebbe influire sulle metriche di reattività delle pagine, come il Tempo di blocco totale (TBT) o il First Input Delay (FID) oltre all'INP.

La soluzione a questo scenario dipende dalla risposta alla domanda: esiste un motivo per cui il markup della pagina non può essere fornito dal server e non viene eseguito il rendering sul client? Se la risposta è "no", il rendering lato server (SSR) o il markup generato in modo statico dovrebbero essere presi in considerazione, ove possibile, poiché aiuteranno lo scanner di precaricamento a rilevare e recuperare in anticipo risorse importanti in modo opportuno.

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

Aiuta lo scanner di precaricamento

Lo scanner di precaricamento è un'ottimizzazione estremamente efficace del browser che consente di caricare più velocemente le pagine durante l'avvio. Evitando schemi che impediscono la possibilità di trovare risorse importanti in anticipo, non solo semplifichi lo sviluppo per conto tuo, ma crei esperienze utente migliori che daranno risultati migliori in molte metriche, tra cui alcune metriche web.

Ricapitolando, ecco alcune cose da evincere da questo post:

• Lo scanner di precaricamento del browser è un parser HTML secondario che esegue la scansione prima di quello principale se è bloccato per rilevare in modo opportuno le risorse che può 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 lo scanner di precaricamento può essere annullato possono includere, a titolo esemplificativo:
  • Iniettare risorse nel DOM con JavaScript, che si tratti di script, immagini, fogli di stile o qualsiasi altra cosa che possa essere migliorata nel payload del markup iniziale dal server.
  • Caricamento lento di immagini o iframe above the fold mediante una soluzione JavaScript.
  • Eseguire il rendering del markup sul client che potrebbe contenere riferimenti alle sottorisorse del documento utilizzando JavaScript.
• Lo scanner di precaricamento analizza solo l'HTML. Non esamina i contenuti di altre risorse, in particolare CSS, che potrebbero includere riferimenti a risorse importanti, tra cui candidati LCP.

Se, per qualsiasi motivo, non puoi evitare un pattern che influisce negativamente sulla capacità dello scanner di precaricamento di accelerare le prestazioni di caricamento, considera il suggerimento della risorsa rel=preload. Se utilizzi rel=preload, esegui un test con gli strumenti di laboratorio per assicurarti che l'effetto ottenuto sia quello desiderato. Infine, non precaricare troppe risorse perché, quando dai priorità a tutto, non succederà nulla.

Risorse

• "Script asincroni" inseriti tramite script considerati dannosi
• In che modo il precaricatore del browser velocizza il caricamento delle pagine
• Precaricare gli asset critici per migliorare la velocità di caricamento
• Stabilire in anticipo le connessioni di rete per migliorare la velocità percepita delle pagine
• Ottimizzazione di Largest Contentful Paint

Immagine hero di Unsplash, di Mohammad Rahmani .