Il percorso di rendering critico si riferisce ai passaggi necessari fino all'avvio del rendering della pagina web nel browser. Per eseguire il rendering delle pagine, i browser hanno bisogno del documento HTML stesso e di tutte le risorse fondamentali necessarie per il rendering del documento.
Il caricamento del documento HTML nel browser era trattato nel precedente modulo Considerazioni generali sul rendimento dell'HTML. In questo modulo, tuttavia, analizzeremo meglio le operazioni svolte dal browser dopo aver scaricato il documento HTML per eseguire il rendering della pagina.
Rendering progressivo
Il web è distribuito per natura. A differenza delle applicazioni native che vengono installate prima dell'uso, i browser non possono dipendere dai siti web che contengono tutte le risorse necessarie per il rendering della pagina. Pertanto, i browser sono molto bravi a eseguire il rendering delle pagine in modo progressivo. Di solito le app native prevedono una fase di installazione e una fase in esecuzione. Tuttavia, per le pagine web e le app web, il confine tra queste due fasi è molto meno distinto e i browser sono stati specificamente progettati in base a questo aspetto.
Quando il browser dispone delle risorse per eseguire il rendering di una pagina, generalmente inizia a farlo. La scelta riguarda quindi quando eseguire il rendering: quando è troppo presto?
Se il browser esegue il rendering il prima possibile quando contiene solo codice HTML, ma prima che abbia il codice CSS o JavaScript necessario, la pagina risulterà temporaneamente non funzionante e cambierà notevolmente per il rendering finale. Si tratta di un'esperienza peggiore rispetto alla visualizzazione iniziale di una schermata vuota per un po' di tempo finché il browser non ha bisogno di più risorse di questo tipo per un rendering iniziale che offra una migliore esperienza utente.
D'altra parte, se il browser attende che tutte le risorse siano disponibili invece di eseguire il rendering sequenziale, l'utente rimarrà in attesa per molto tempo, spesso inutilmente se la pagina era utilizzabile in un momento molto precedente.
Il browser deve sapere qual è il numero minimo di risorse che deve attendere per evitare di presentare un'esperienza chiaramente interrotta. D'altra parte, il browser non deve attendere più a lungo del necessario prima di presentare all'utente alcuni contenuti. La sequenza di passaggi che il browser esegue prima di eseguire il rendering iniziale è nota come percorso di rendering critico.
Comprendere il percorso di rendering critico può aiutarti a migliorare le prestazioni web assicurandoti di non bloccare il rendering iniziale delle pagine più del necessario. Allo stesso tempo, tuttavia, è importante non consentire che il rendering venga eseguito troppo presto, rimuovendo le risorse necessarie per il rendering iniziale dal percorso di rendering critico.
Il percorso di rendering (critico)
Il percorso di rendering prevede i seguenti passaggi:
- Creazione del DOM (Document Object Model) dal codice HTML.
- Creazione del CSSOM (CSS Object Model) a partire dal CSS.
- Applicazione di qualsiasi codice JavaScript che modifichi il DOM o il CSSOM.
- Creazione dell'albero di rendering dal DOM e dal CSSOM.
- Esegui operazioni di stile e layout sulla pagina per vedere quali elementi si adattano alla posizione.
- Colora i pixel degli elementi in memoria.
- Componi i pixel se si sovrappongono.
- Disegna fisicamente tutti i pixel risultanti sullo schermo.
L'utente vedrà i contenuti sullo schermo solo al termine di tutti questi passaggi.
Questo processo di rendering avviene più volte. Il rendering iniziale richiama questo processo, ma man mano che diventano disponibili altre risorse che influiscono sul rendering della pagina, il browser esegue nuovamente il processo (o magari solo alcune parti) per aggiornare ciò che vede l'utente. Il percorso di rendering critico si concentra sul processo descritto in precedenza per il rendering iniziale e dipende dalle risorse fondamentali necessarie.
Quali risorse si trovano nel percorso di rendering critico?
Il browser deve attendere il download di alcune risorse critiche prima di poter completare il rendering iniziale. tra cui:
- Parte del codice HTML.
- Blocco della visualizzazione CSS nell'elemento
<head>. - Rendering di JavaScript nell'elemento
<head>.
Un punto fondamentale è che il browser elabora l'HTML in modalità flusso. Non appena il browser riceve una porzione del codice HTML di una pagina, inizia a elaborarla. Il browser può quindi (e spesso lo fa) decidere di eseguire il rendering prima di ricevere il resto del codice HTML di una pagina.
È importante sottolineare che, per la visualizzazione iniziale, il browser in genere non aspetta:
- Tutto il codice HTML.
- Caratteri.
- Immagini.
- JavaScript che non blocca il rendering all'esterno dell'elemento
<head>(ad esempio, elementi<script>posizionati alla fine del codice HTML). - CSS che non blocca il rendering al di fuori dell'elemento
<head>o CSS con un valore dell' attributomediache non si applica all'area visibile corrente.
I caratteri e le immagini sono spesso considerati dal browser come contenuti da compilare durante il rendering successivo della pagina, quindi non è necessario attendere il rendering iniziale. Ciò, tuttavia, può significare che rimangono aree vuote nel rendering iniziale mentre il testo è nascosto in attesa dei caratteri o finché non sono disponibili le immagini. Peggio ancora si verifica quando lo spazio a sufficienza non è riservato a determinati tipi di contenuti, in particolare quando le dimensioni dell'immagine non sono fornite nel codice HTML, il layout della pagina può variare quando questi contenuti verranno caricati in un secondo momento. Questo aspetto dell'esperienza utente viene misurato dalla metrica Cumulative Layout Shift (CLS).
L'elemento <head> è fondamentale per l'elaborazione del percorso di rendering critico. Tanto che nella prossima sezione l'argomento verrà trattato in modo dettagliato. L'ottimizzazione dei contenuti dell'elemento <head> è un aspetto chiave del rendimento sul web. Per il momento, però, per comprendere il percorso di rendering critico, ti basta sapere che l'elemento <head> contiene metadati relativi alla pagina e alle sue risorse, ma non contenuti effettivi che l'utente può vedere. I contenuti visibili sono contenuti all'interno dell'elemento <body> che segue l'elemento <head>. Per poter eseguire il rendering dei contenuti, il browser ha bisogno sia dei contenuti da visualizzare sia dei metadati su come eseguirli.
Tuttavia, non tutte le risorse a cui viene fatto riferimento nell'elemento <head> sono strettamente necessarie per il rendering iniziale della pagina, quindi il browser attende solo quelle che sono. Per identificare le risorse che si trovano nel percorso di rendering critico, devi conoscere le risorse CSS e JavaScript che bloccano la visualizzazione e il parser.
Risorse che bloccano la visualizzazione
Alcune risorse sono considerate così critiche che il browser mette in pausa il rendering della pagina fino a quando non le ha gestite. CSS rientra in questa categoria per impostazione predefinita.
Quando un browser rileva il codice CSS, che si tratti di CSS incorporato in un elemento <style> o di una risorsa a cui viene fatto riferimento esternamente, specificata da un elemento <link rel=stylesheet href="...">, il browser evita di visualizzare altri contenuti fino a quando non ha completato il download e l'elaborazione del CSS.
Solo perché una risorsa blocca il rendering, non significa necessariamente che il browser non faccia altro. I browser cercano di essere il più efficienti possibile, pertanto, quando un browser vede di dover scaricare una risorsa CSS, la richiede e mette in pausa il rendering, ma continuerà comunque a elaborare il resto del codice HTML e cercherà nel frattempo altre operazioni da svolgere.
Le risorse che bloccano la visualizzazione, come i CSS, erano utilizzate per bloccare l'intero rendering della pagina quando sono state rilevate. Ciò significa che il blocco o meno del rendering di un codice CSS dipende dal fatto che il browser l'abbia rilevato o meno. Alcuni browser (inizialmente Firefox e ora anche Chrome) bloccano solo il rendering dei contenuti al di sotto della risorsa che blocca il rendering. Ciò significa che per il percorso critico di blocco della visualizzazione,
di solito siamo interessati alle risorse che bloccano la visualizzazione in <head>, poiché
bloccano effettivamente il rendering dell'intera pagina.
Un'innovazione più recente è l'attributo blocking=render, aggiunto a
Chrome 105. In questo modo gli sviluppatori possono contrassegnare esplicitamente un elemento <link>, <script> o <style> come blocco del rendering fino all'elaborazione dell'elemento, consentendo comunque all'analizzatore sintattico di continuare a elaborare il documento nel frattempo.
Risorse di blocco del parser
Le risorse di blocco del parser sono quelle che impediscono al browser di cercare altre operazioni continuando ad analizzare il codice HTML. Per impostazione predefinita, JavaScript blocca il parser (a meno che non sia specificamente contrassegnato come asincrono o differito), poiché JavaScript può modificare il DOM o il CSSOM al momento dell'esecuzione. Pertanto, il browser non può continuare a elaborare altre risorse finché non riconosce l'impatto completo del codice JavaScript richiesto sul codice HTML di una pagina. Il codice JavaScript sincrono blocca quindi l'analizzatore sintattico.
Anche le risorse di blocco del parser bloccano la visualizzazione. Poiché l'analizzatore non può proseguire oltre una risorsa di blocco dell'analisi fino a quando non è stata completamente elaborata, non può accedere ai contenuti successivi e visualizzarli. Il browser è in grado di visualizzare qualsiasi codice HTML ricevuto finora durante l'attesa, ma se è interessato il percorso di rendering critico, eventuali risorse che bloccano l'analizzatore sintattico in <head> indicano di fatto che il rendering di tutti i contenuti della pagina è bloccato.
Bloccare il parser può comportare notevoli costi in termini di prestazioni, molto di più del semplice blocco del rendering. Per questo motivo, i browser cercheranno di ridurre questo costo utilizzando un parser HTML secondario noto come scanner di precaricamento per scaricare le risorse successive mentre l'analizzatore sintattico HTML principale è bloccato. Sebbene non sia efficace quanto l'analisi del codice HTML, consente almeno alle funzioni di networking del browser di funzionare prima dell'analizzatore sintattico bloccato, il che significa che è meno probabile che venga nuovamente bloccato in futuro.
Identificazione delle risorse di blocco
Molti strumenti di controllo delle prestazioni identificano le risorse che bloccano il rendering e il parser. WebPageTest contrassegna le risorse che bloccano il rendering con un cerchio arancione a sinistra dell'URL della risorsa:
Tutte le risorse che bloccano il rendering devono essere scaricate ed elaborate prima dell'avvio del rendering, come indicato dalla linea verde scuro nella struttura a cascata.
Lighthouse evidenzia anche le risorse che bloccano il rendering, ma in modo più discreto, solo se la risorsa ritarda effettivamente il rendering della pagina. Questo può essere utile per evitare falsi positivi, laddove altrimenti riduci al minimo il blocco del rendering. L'esecuzione dello stesso URL di pagina del precedente elemento WebPageTest tramite Lighthouse identifica solo uno dei fogli di stile come risorsa che blocca il rendering.
Ottimizzazione del percorso di rendering critico
L'ottimizzazione del percorso di rendering critico comporta la riduzione del tempo per ricevere il codice HTML (rappresentato dalla metrica Time to First Byte (TTFB)) come descritto nel modulo precedente, nonché la riduzione dell'impatto delle risorse che bloccano la visualizzazione. Questi concetti verranno analizzati nei prossimi moduli.
Il percorso di rendering con contenuti critici
Per molto tempo, il percorso di rendering critico ha interessato a lungo il rendering iniziale. Tuttavia, sono emerse altre metriche incentrate sull'utente per le prestazioni sul web, il che mette in dubbio se il punto finale del percorso di rendering critico debba essere la prima visualizzazione o una delle versioni più soddisfacenti successive.
In alternativa, puoi concentrarti sul tempo che manca alla Largest Contentful Paint (LCP), o anche alla First Contentful Paint (FCP), come parte di un percorso di rendering con contenuti contenuti (o percorso chiave come potrebbe essere chiamato altri). In questo caso, potrebbe essere necessario includere risorse che non bloccano necessariamente, come è stata la definizione tipica del percorso di rendering critico, ma che sono necessarie per il rendering di contenuti con contenuti.
Indipendentemente dalla tua definizione esatta di ciò che definisci come "critico", capire cosa determina qualsiasi visualizzazione iniziale e i tuoi contenuti chiave è importante. La prima visualizzazione misura la prima opportunità possibile di eseguire il rendering di qualsiasi cosa per l'utente. Idealmente, dovrebbe avere qualcosa di significativo, ad esempio un colore di sfondo, ma anche se non è né contenuto, è comunque utile presentare something all'utente, che è un argomento per misurare il percorso di rendering critico come viene definito tradizionalmente. Allo stesso tempo, è utile anche misurare il momento in cui i contenuti principali vengono presentati all'utente.
Identificare il percorso di rendering con contenuti
Molti strumenti sono in grado di identificare gli elementi LCP e quando vengono visualizzati. Oltre all'elemento LCP, Lighthouse ti aiuta anche a identificare le fasi LCP e il tempo speso in ognuna per aiutarti a capire su quali aspetti concentrare meglio i tuoi sforzi di ottimizzazione:
Per i siti più complessi, Lighthouse evidenzia anche catene di richieste critiche in un controllo separato:
Questo controllo Lighthouse osserva tutte le risorse caricate con priorità elevata, quindi include caratteri web e altri contenuti che Chrome imposta come risorsa ad alta priorità, anche se in realtà non bloccano il rendering.
verifica le tue conoscenze
A cosa si riferisce il percorso di rendering critico?
Quali risorse sono coinvolte nel percorso di rendering critico?
<head>.<head>.Perché il blocco del rendering è una parte necessaria del rendering delle pagine?
Perché JavaScript blocca l'analizzatore sintattico HTML (supponendo che gli attributi defer, async o module non siano specificati in un elemento <script>)?
<script> sta bloccando e bloccando la visualizzazione.A seguire: caricamento delle risorse di Optimize
Questo modulo ha trattato alcune teorie alla base del modo in cui il browser esegue il rendering di una pagina web e, in particolare, ciò che è necessario per completare il rendering iniziale di una pagina. Nel modulo successivo vedremo come ottimizzare questo percorso di rendering imparando come ottimizzare il caricamento delle risorse.