Percorso di rendering critico: cos’è e come funziona

Il Web si è molto evoluto rispetto a quello di circa 20-30 anni fa. Un tempo le pagine web erano per la maggior parte formate da solo testo e collegamenti ipertestuali, in virtù della bassa velocità della connessione analogica in 56k o Dial-up. Con la diffusione della banda larga i siti web iniziarono ad essere sempre più arricchiti di immagini ed a fine anni ’90, con l’avvento della seconda versione dei fogli di stile, in gergo CSS, anche il layout migliorò notevolmente, introducendo la figura del web designer.

Parallelamente nacque l’esigenza di rendere le pagine web pagine interattive mediante l’utilizzo di appositi software eseguiti lato client – dal browser – i cosiddetti script. Sebbene ve ne siano di diversi, il linguaggio più diffuso è sicuramente Javascript. E fu così che ad inizio anni 2000 nacquero le web application. 

Se da una parte il progresso ha portato allo sviluppo di nuovi sistemi e metodologie di interazione, offrendo ai visitatori contenuti ed esperienze di navigazione fino a poco tempo fa inimmaginabili, dal punto di vista dei professionisti è sicuramente calata la peculiarità nelle performance, sia nel risparmio del singolo byte trasferito (performance networking) che elaborato (performance applicazione). Di fatto oggi, nonostante la tecnologia sia evoluta e la banda larga e ultra-larga distribuita, ci ritroviamo di fronte a molti siti web percepiti come lenti.

È luogo comune in questi casi scaricare le colpe all’hosting provider, ma siamo sicuri che sia davvero così? Siamo sicuri che il problema non risieda nell’applicazione web, nella sua forma e progettazione? Per capirlo bisogna comprendere ed analizzare il percorso di rendering che il browser effettua ogni qual volta elabora una pagina web.

Il percorso di rendering

Per capire come ottimizzare un sito web, un qualsiasi sito web, occorre prima di tutto capire come un browser elabora la richiesta di una pagina web prima di fornirla all’utente, ovvero tutto ciò che accade tra il momento in cui inviamo la richiesta ad un sito web e quello in cui vediamo le prime informazioni a video.

Costruzione del DOM

Quando il browser riceve dal server il codice HTML della pagina richiesta, ne inizia il parsing, ovvero la lettura e la decodifica. Man mano che il parser del browser legge e decodifica il codice HTML inizia la creazione incrementale del DOM, acronimo di Document Object Model, una sorta di mappa dove i tag HTML vengono relazionati in una struttura ad albero ricorsiva padre-figlio. 

Naturalmente più è complesso il codice HTML e più complessa sarà la struttura DOM. Il problema è che essendo la struttura ad albero per natura leggibile solo in modalità ricorsiva, tag in più inutili impattano molto negativamente sull’uso di memoria RAM e CPU del client, rallentandone l’intero processo. Special modo per dispositivi dotati di risorse limitate, come i dispositivi mobile, l’ottimizzazione del codice HTML può avere un grande impatto.

In un sito web moderno purtroppo non basta il solo DOM per poter procedere alla visualizzazione della pagina. Questo infatti acquisisce proprietà e relazioni tra i vari tag che compongono il documento HTML ma non ci informa in alcun modo sull’aspetto. Questa responsabilità è data a CSSOM.

Costruzione del CSSOM

Durante il parsing per la costruzione del DOM, il browser si trova di fronte ad un tag <link> che fa riferimento ad un CSS. Egli capisce che tale risorsa sarà necessaria per il rendering della pagina per cui ne fa subito esplicita richiesta al server per poterne leggere il contenuto. In caso di CSS inline in tag <style> tutto rimane invariato a parte per il fatto che essendo il contenuto già espresso non occorre effettuare alcuna richiesta al server.

Proprio come accade per i tag HTML, anche in questo caso il browser costruisce una struttura ad albero che chiama CSSOM, acronimo di CSS Object Model. 

Essendo anch’essa una struttura ad alberto, i figli ereditano le proprietà dei padri. Come per il DOM, più le regole CSS sono complesse ed elaborate, maggiore complessità avrà la struttura del CSSOM e più tempo, memoria e CPU richiederà al browser la sua elaborazione. Quindi il primo consiglio è quello di scrivere CSS semplici e puliti.

Inoltre a differenza del DOM la costruzione del CSSOM non è incrementale. Per essere costruito, infatti, è necessario che il browser prima riceva il contenuto di tutti i CSS presenti nel documento, siano loro inline che esterni. Come ottimizzare questa parte? Ne parleremo successivamente nel tutorial dedicato all’ottimizzazione dei contenuti in above the fold, intanto vi basta sapere che più CSS sono presenti, maggiore sarà il tempo impiegato per poter avere tutti gli ingredienti necessari per visualizzare la pagina. Evitate dunque di includere CSS non utilizzati dalla pagina in corso di scansione.

Render Tree, Layout e Paint

Una volta realizzati DOM e CSSOM, il browser li combina per realizzare il render tree il quale viene usato per elaborare il layout di ciascun elemento che serve come input per il processo di paint che trasforma i pixel in elementi visibili su schermo. L’ottimizzazione di questi passaggi è fondamentale per ottenere prestazioni ottimali di rendering.

Per la costruzione del render tree, il browser effettua approssimativamente i seguenti passaggi:

1. Inizia a scansionare i nodi del DOM ed identifica quelli visibili. Alcuni nodi non sono visibili in quanto fanno riferimento a tag HTML che non hanno una corrispondenza visiva (script, meta tag, ecc..) altri  invece sono nascosti da regole CSS (display: none; visibility: hidden; ecc..);
2. Per ogni nodo visibile cerca ed elabora le rispettive regole CSS trovate nel CSSOM;
3. Pubblica i nodi visibili con il rispettivo contenuto e stili.

A questo punto è possibile procedere con la costruzione del layout. Questa parte di elaborazione si occupa di fornire ad ogni nodo una dimensione e posizione all’interno dello schermo in funzione della viewport, ovvero le dimensioni dello schermo in se che variano da dispositivo a dispositivo.

Adesso che conosciamo i nodi visibili e per ognuno di essi contenuto, stile e geometria, possiamo passare all’ultimo step che converte ogni nodo del render tree in pixel veri a propri da visualizzare a video. Questo passaggio prende il nome di Paint che finalmente determina la visualizzazione della pagina all’utente.

E il javascript?

I più attenti tra voi si chiederanno: ma il Javascript come influenza tutto questo processo? Cosa accade quando il browser incontra uno script durante il parsing HTML?

Uno script Javascript è il male assoluto per le performance di un sito web in quanto forza il blocco di tutto il processo di parsing per poter essere eseguito. Perché? Sostanzialmente perché lo script potrebbe alterare la struttura del DOM, ad esempio mediante l’utilizzo di document.write, ed anche perché potrebbe effettuare query al CSSOM.

Non potendo sapere in anteprima se lo script effettuerà o meno modifiche al DOM o query al CSSOM, il parser blocca la naturale costruzione del DOM, scarica lo script – se esterno – lo esegue e poi riprende il parsing. Un ulteriore problema è dato dal CSSOM. Come già detto, questo viene costruito solo dopo aver letto il codice di tutti i CSS presenti nella pagina e siccome lo script potrebbe interpellarlo, prima di essere eseguito occorre che il browser crei il CSSOM, ulteriore ritardo indotto.

Successivamente vi illustrerò come ottimizzare il caricamento degli script Javascript per renderli non bloccanti con un drastico incremento delle performance dell’intero sito web.

Riepilogo

Riepilogando, il percorso critico è quella sequenza di passi ed elaborazioni necessarie per poter visualizzare la pagina web a video. Durante il parsing è possibile incontrare risorse critiche come CSS e Javascript che, se non ottimizzate, incidono molto negativamente sul tempo di visualizzazione della pagina e quindi sulla percezione della velocità del sito web dal punto di vista utente.

Di seguito gli step eseguiti dal browser:

1. Parsing del codice HTML e costruzione incrementale del DOM;
2. Parsing di tutto il codice CSS e successiva costruzione del CSSOM;
   • Esecuzione di eventuale codice Javascript intermedio;
3. Combinazione di DOM e CSSOM per la costruzione del Render Tree;
4. Esecuzione del  processo di layout per la realizzazione della geometria dei singoli nodi del Render Tree;
5. Trasformazione in pixel e visualizzazione della pagina.

Conclusione

L’ottimizzazione del percorso di rendering critico è la base delle performance per ogni sito web, sia esso realizzato in WordPress, Joomla o da zero. Comprendere il funzionamento del browser è fondamentale per capire quali risorse incidono sul tempo di visualizzazione e caricamento della pagina e come.

Negli articoli successivi verrà illustrato come misurare il percorso critico e come identificare ed ottimizzare le singole risorse creando delle vere e proprie politiche di ottimizzazione, perché ogni pagina del sito funziona in modo diverso e richiede accorgimenti diversi anche in funzione del modello di business adottato.