path: root/files/it/web/performance/critical_rendering_path/index.html

---
title: Percorso critico di rendering
slug: Web/Performance/Percorso_critico_di_rendering
translation_of: Web/Performance/Critical_rendering_path
---
<p>{{draft}}</p>

<p><span class="seoSummary">Il <strong>Percorso Critico di Rendering </strong>(in inglese: Critical Rendering Path, <strong>CRP</strong>) è la sequenza di passi che il browser compie per convertire HTML, CSS e Javascript in pixel sullo schermo. Ottimizzare il CRP migliora la performance. Il percorso include il</span><span class="seoSummary"><a href="/en-US/docs/Web/API/Document_Object_Model">Document Object Model </a>(DOM), il <a href="/en-US/docs/Web/API/CSS_Object_Model">CSS Object Model </a>(CSSOM), l'albero di rendering e il layout.</span></p>

<p>Il DOM è creato man mano che l'HTML viene parsificato. L'HTML può richiedere Javascript, il quale potrebbe a sua volte alterare il <strong>DOM</strong>. L'HTML include o richiede fogli di stile, la cui parsificazione costruisce il <strong>CSSOM</strong>. Il motore del browser combina il DOM e il CSSOM per costruire l'albero di rendering. La fase di layout determina le dimensioni e posizione di ogni elemento della pagine. Infine, i pixel sono dipinti sullo schermo.</p>

<p>Ottimizzare il CRP migliora il tempo che il browser impiega ad effettuare il primo render. Capire e ottimizzare il percorso critico di rendering è importante per assicurarsi che i reflow e repaint vengano effettuato a 60 frame al secondo, risultando in una migliore esperienza per l'utente.</p>

<h2 id="Capire_il_CRP">Capire il CRP</h2>

<p>La performance di un sito web dipende dal tempo impiegato per effettuare richieste al server, risposte, caricare risorse, eseguire script, rendering, layout, e dipingere i pixel sullo schermo.</p>

<p>Una richiesta per una pagina web o una web app inizia con una richiesta HTML. Il server risponde alla richiesta con il codice sorgente in linguaggio HTML. A questo punto, il browser inizia a parsificare l'HTML, costrudendo l'albero DOM.</p>

<p>Il browser manda ulteriori richieste ogni volta che trova link a risorse esterne, che siano fogli di stile, script, o referenze a immagini. Alcune richieste sono <strong>bloccanti</strong>, il che significa che la parsificazione del resto dell'HTML viene interrotta fino a quando la risorsa importata non viene scaricata e manipolata. In seguito, il browser continua a parsificare l'HTML fino ad arrivare alla fine del file. A questo punto, il browser comincia a costruire il CSSOM. Quando il DOM e il CSSOM sono completi, il browser costruisce l'albero di rendering, calcolando gli stili per tutto il contenuto visibile. Quando l'albero è completo, viene calcolato il layout, che definisce le dimensioni e posizione di tutti gli elementi dell'albero di rendering. Una volta completato, la pagina viene "dipinta" sullo schermo.</p>

<h3 id="Document_Object_Model">Document Object Model</h3>

<p>La costruzione del DOM è incrementale. La risposta HTML si transforma in token, la quale si trasforma in nodi che costituiscono l'albero DOM. Un singolo nodo DOM comincia con un token startTag e finisce con un token endTag. I nodi contengono tutte le informazioni rilevanti sull'elemento HTML, descritta attraversi i token. I nodi sono connessi in un albero DOM in base alla gerarchia dei token. Per esempio, se un paio di token startTag ed endTag appaiono nel mezzo di un altro paio, questo genera un nodo padre ed un nodo figlio.</p>

<p>Un grande numero di nodi può dunque impattare la performance, complicando il critical rendering path.</p>

<h3 id="CSS_Object_Model">CSS Object Model</h3>

<p>Il DOM contiene l'intero contenuto della pagina. il CSSOM contiene tutti gli stili. La costruzione del DOM è incrementale, ma quella del CSSOM non lo è. Il CSS è render-blocking: il browser blocca il rendering di una pagina finché non riceve e processa tutto il CSS. Questo perché le regole possono essere sovrascritte, quindi il contenuto non può essere mostrato fino a quando il CSS non è completo. </p>

<p>Il CSS ha le proprie regole per identificare token validi. Quando il parser converte i token in nodi, i nodi discendenti ereditano regole dai genitori. Il CSSOM viene costruito mentre il CSS viene parsificato, ma non può essere usato per costruire il render tree fino a quando la parsificazione viene completata perché stili che vengono sovrascritti in seguito non devono essere visualizzati.</p>

<p>Selettori meno specifici sono più performanti. Per esempio, <code>.foo {}</code> è più veloce di <code>.bar .foo {}</code> perché quando il browser trova <code>.foo</code>, nel secondo scenario, deve salire nel DOM per controllare se <code>.foo</code> ha un genitore <code>.bar</code>.</p>

<p>I browser processano il CSS molto rapidamente. La regola specifica è più lenta perché deve attraversare più nodi nell'albero DOM, ma questo costo aggiuntivo è solitamente minimo. L'ottimizzazione dei selettori CSS solitamente porta a velocizzazioni nell'ordine dei microsecondi. Ci sono altri modi più efficaci per ottimizzare il CSS, come la mininizzazione, e separare il CSS in richieste non-blocking usando media queries.</p>

<h3 id="Lalbero_di_rendering">L'albero di rendering</h3>

<p>L'albero di rendering cattura sia il contenuto che gli stili combinando il DOM ed il CSSOM. Per costruirlo, il browser controlla ogni nodo, a partire dalla radice dell'albero DOM, e determina quali regole CSS sono applicate al nodo.</p>

<p>L'albero di rendering mantiene informazioni solo su elementi visibili. La sezione head solitamente non contiene informazioni visibili, e quindi non è inclusa. Se display: none; è settato su un elemento, né questo elemento né i suoi discendenti sono inclusi.</p>

<h3 id="Layout">Layout</h3>

<p>Quando l'albero di rendering è completamente costruito, il layout diventa possibile. Il layout dipende dalle dimensioni dello schermo e determina dove e come gli elementi sono posizionati nella pagina, inclusi largezza ed altezza di ogni elemento, e dove sono posizionati rispetto ad altri elementi.</p>

<p>Elementi block-level hanno una largezza in default di 100% del genitore. L'elemento body ha una larghezza dal 100% del viewport.</p>

<p>Il meta tag "viewport" definisce la larghezza del viewport. In assenza di questo tag, il browser usa la larghezza viewport di default, che su browser a tutto schermo è solitamente 960px. Su browser a tutto schermo, come il browser degli smartphone, il settaggio <code>&lt;meta name="viewport" content="width=device-width"&gt;</code> fa in modo che la larghezza sarà quella del dispositivo invece di quella di default. La device-width cambia quando l'utente ruota il telefono tra modalità landscape e ritratto. Il layout viene calcolato ogni volta che un dispositivo viene ruotato o il browser viene in qualche modo ridimensionato.</p>

<p>La performance della fase di layout è impattato dal numero di nodi nel DOM. La fase di layout può diventare un collo di bottiglia se richiesto durante lo scorrimento del mouse o altre animazioni. Un ritardo di 20ms al caricamento della pagina o al cambiamento di orientamento è accettabile, ma potrebbe portare a problemi se avviene durante lo scorrimento del mouse o durante animazioni. Ogni volta che l'albero di rendering è modificato, il passo di layout viene eseguito.</p>

<p>Per ridurre la frequenza e durate degli eventi di layout, è consigliabile effettuare un batch degli aggiornamenti ed evitare di animare proprietà del box model.</p>

<h3 id="Paint">Paint</h3>

<p>L'ultimo passo è mostrare i pixel sullo schermo. Questo può avvenire quando l'albero di rendering è creato e il layout calcolato. L'intero schermo è dipinto quando la pagina viene caricata. Successivamente, solo le parti dello schermo interessate verranno ridipinte grazie alle ottimizzazioni dei browser moderni. Il tempo necessario a un repaint è solitamente molto veloce, ma è importante ricordarsi di conteggiare il tempo di layout e ripittura quando si misura il tempo richiesto da un animation frame.</p>

<h2 id="Optimizing_for_CRP">Optimizing for CRP</h2>

<p>Improve page load speed by prioritizing which resources get loaded, controlling the order in which they area loaded, and reducing the file sizes of those resources. Performance tips include 1) minimizing the number of critical resources by deferring their download, marking them as async, or eliminating them altogether, 2) optimizing the number of requests required along with the file size of each request, and 3) optimizing the order in which critical resources are loaded by prioritizing the downloading critical assets, shorten the critical path length.</p>