L’Ottimizzazione del Critical Rendering Path \u00e8 il processo di riduzione al minimo del tempo impiegato dal browser per eseguire ogni fase della sequenza, dando priorit\u00e0 alla visualizzazione dei contenuti relativi all’azione corrente dell’utente.<\/p><\/blockquote>\n
Gran parte di questo processo riguarda la porzione di pagina visibile senza scorrere la finestra del browser. Questa sezione \u00e8 conosciuta anche come “Above the Fold<\/strong>“. Per una migliore usabilit\u00e0, l’ATF dovrebbe essere reso a video il pi\u00f9 presto possibile, e questo pu\u00f2 essere realizzato riducendo al minimo il numero dei round trip di rete. Le risorse necessarie per il rendering dell’ATF sono considerate critiche, e ottimizzare l’Above the Fold significa minimizzare l’impatto delle risorse critiche sul tempo del primo rendering della pagina.<\/p>\n In questo articolo, analizzeremo la sequenza di ottimizzazione del Percorso di Rendering Critico.<\/p>\n Ecco la sequenza dei passaggi eseguiti dal browser per rendere una pagina:<\/p>\n Come spiegato anche nella Guida all’Ottimizzazione del Percorso di Rendering Critico<\/a> di Google, il browser costruisce il Document Object Model in una sequenza di quattro passaggi:<\/p>\n Ci\u00f2 che \u00e8 importante notare qui \u00e8 che il browser costruisce il DOM in modo incrementale. Questo ci d\u00e0 l’opportunit\u00e0 di velocizzare il rendering della pagina creando strutture DOM efficienti.<\/p>\n Quando il parser incontra un tag A differenza della costruzione del DOM, la costruzione del CSSOM non \u00e8 incrementale. Il browser non pu\u00f2 utilizzare una porzione di un foglio di stile, perch\u00e9 gli stili possono essere ridefiniti e ridichiarati nello stesso foglio di stile. Per questo motivo, il browser blocca il processo di rendering fino a quando non riceve e analizza tutti i CSS. Ci\u00f2 significa che CSS blocca il rendering<\/strong>.<\/p>\n Il browser combina DOM e CSSOM nel Render Tree, che \u00e8 la struttura ad albero finale contenente tutti i nodi e le propriet\u00e0 che vengono utilizzati per rendere la pagina sullo schermo.<\/p>\n Il Render Tree contiene solo i nodi necessari per rendere una pagina. Di conseguenza, i nodi invisibili vengono omessi.<\/p><\/blockquote>\n Il browser utilizza il Render Tree per calcolare le dimensioni e la posizione del nodo e, in ultima analisi, come input per il processo di resa a video.<\/p>\n Nella fase di layout, il browser calcola le dimensioni e la posizione di ogni nodo del Render Tree. In questa fase, il browser attraversa il Render Tree partendo dalla sua radice e produce un box model. Queste informazioni vengono infine utilizzate per convertire ogni nodo del Render Tree in pixel reali sullo schermo.<\/p>\n Il tempo necessario per eseguire l’intero processo pu\u00f2 essere variabile. Dipende da molti fattori, come la dimensione del documento, il numero di richieste, gli stili applicati, il dispositivo dell’utente, ecc. Come ben spiegato nella guida di PageSpeed di Google<\/a>, se la quantit\u00e0 di dati necessari per rendere l’ATF supera la finestra di congestione iniziale (14,6kb), saranno necessari altri round trip di rete tra il server e il browser. Sulle reti mobili, con latenze elevate, ci\u00f2 ritarderebbe notevolmente il caricamento delle pagine (per saperne di pi\u00f9 sulla latenza<\/a>). Ma l’ottimizzazione non si esaurisce con la costruzione di una struttura DOM efficiente. Si tratta piuttosto di un processo di miglioramento e di misurazione che coinvolge l’intera sequenza del Percorso di Rendering Critico.<\/p>\n Approfondiamo.<\/p>\n Possiamo ridurre la quantit\u00e0 di dati che il browser sta per scaricare tramite la minificazione, la compressione e il caching delle risorse HTML, CSS e JavaScript:<\/p>\n Ora sappiamo che il browser deve attendere che recuperi ed elabori il codice CSS prima di poter rendere la pagina (CSS blocca il rendering<\/a>). Ma non tutte le risorse CSS bloccano il rendering<\/strong>. Il foglio di stile di riferimento di questo tag si applica in qualsiasi condizione, indipendentemente dal tipo di supporto corrente, dalla risoluzione dello schermo, dall’orientamento del dispositivo, ecc. Questo significa che la risorsa CSS blocca sempre il rendering. Il browser scarica ancora il foglio di stile print.css<\/i>, ma non blocca il rendering. Inoltre, il browser deve scaricare meno dati per il file CSS principale e questo ci aiuterebbe a velocizzare il download. Possiamo specificare qualsiasi media query sull’attributo Assicuratevi che i vostri stili siano effettivamente necessari per rendere la pagina. Se non lo sono, potreste aggiungere un valore appropriato all’attributo media del tag e sbloccare il rendering.<\/p>\n I media type e le query possono aiutarci a velocizzare il rendering delle pagine, ma possiamo fare molto di pi\u00f9.<\/p>\n Potete dare un bell’impulso al vostro sito minificando il codice direttamente dal vostro cruscotto MyKinsta<\/a>. \u00c8 sufficiente usare la funzione di minificazione del codice<\/a> messa a disposizione per attivare la modifica automatica di CSS e Javascript con un semplice clic.<\/p>\n Il tempo impiegato dal browser per impaginare il documento dipende dal numero di elementi del DOM da impaginare e dalla complessit\u00e0 del layout.<\/p>\n Il calcolo delle dimensioni e della posizione degli elementi richiede tempo e riduce le prestazioni. Rendere il DOM il pi\u00f9 semplice possibile ed evitare l’uso di JavaScript per anticipare il processo di layout aiuterebbe il browser a velocizzare il rendering delle pagine (per saperne di pi\u00f9 sull’ottimizzazione del layout<\/a>).<\/p>\n Strettamente connesso al Layout \u00e8 il processo di resa grafica, che \u00e8 probabilmente la fase che richiede pi\u00f9 tempo nella sequenza del Critical Rendering Path perch\u00e9, ogni volta che si modifica il layout di un elemento o qualsiasi propriet\u00e0 non geometrica, il browser attiva un evento paint. Fare le cose nel modo pi\u00f9 semplice possibile in questa fase potrebbe aiutare il browser ad accelerare il processo di visualizzazione. Per esempio, una propriet\u00e0 L’ottimizzazione del processo di resa grafica (paint) pu\u00f2 non essere cos\u00ec facile, e si dovrebbero utilizzare gli strumenti di sviluppo del browser per misurare il tempo che il browser impiega per attivare ogni evento paint. Potete leggere di pi\u00f9 su questo argomento nella guida Rendering Performance di Google<\/a>.<\/p>\n Quando il browser incontra un tag script, deve interrompere il parsing del codice HTML. Gli script in linea vengono eseguiti nel punto esatto in cui si trovano nel documento e bloccano la costruzione del DOM fino a quando il motore JS termina la sua esecuzione. In altre parole, JavaScript in linea pu\u00f2 ritardare notevolmente il rendering iniziale della pagina. Ma JavaScript permette anche di manipolare le propriet\u00e0 CSS, quindi il browser deve mettere in pausa l’esecuzione dello script fino a quando non ha finito di scaricare e costruire il CSSOM. Ci\u00f2 significa che JavaScript causa il blocco del parsing<\/strong>.<\/p>\n Nel caso di file JS esterni, il parser deve anche attendere che la risorsa sia stata recuperata dalla cache o dal server remoto, e questo potrebbe rallentare pesantemente il tempo necessario al primo rendering della pagina. Sono un sacco di cose da ricordare, vero? Tiriamo un attimo il fiato e facciamo un riepilogo delle azioni di ottimizzazione descritte finora.<\/p>\n Ora che conosciamo i concetti di base dell’Ottimizzazione del Critical Rendering Path, possiamo dare un’occhiata ad alcuni popolari plugin di ottimizzazione di WordPress.<\/p>\n Gli utenti di WordPress possono usufruire di una serie di plugin che coprono quasi ogni fase del processo di ottimizzazione. Si pu\u00f2 installare un plugin completo, oppure si possono installare pi\u00f9 plugin contemporaneamente, ognuno dei quali fornisce specifiche funzionalit\u00e0 di ottimizzazione.<\/p>\n Se il vostro sito \u00e8 ospitato da Kinsta, non avrete bisogno di un plugin per il caching perch\u00e9 non sono necessari plugin per il caching di WordPress su Kinsta<\/a>.<\/p><\/blockquote>\n Questo singolo plugin copre quasi tutte le fasi del processo di ottimizzazione del Percorso di Rendering Critico. A prima vista la configurazione del plugin pu\u00f2 essere scoraggiante, ma una volta acquisita una maggiore familiarit\u00e0 con la sequenza del Critical Rendering Path, si potr\u00e0 beneficiare di un potente set di strumenti di performance.<\/p>\n Ecco un elenco di alcune funzionalit\u00e0 del plugin:<\/p>\n Queste sono solo alcune delle tante caratteristiche di W3TC. Potete leggere di pi\u00f9 su tutte le funzionalit\u00e0, le impostazioni e le opzioni del plugin<\/a> in questa guida dettagliata.<\/p>\n WP Super Cache<\/a>\u00a0\u00e8 un altro popolare plugin per le prestazioni del sito.<\/p>\n Il plugin \u00e8 dotato di un buon numero di funzioni di ottimizzazione, ma \u00e8 meno completo del precedente W3 Total Cache e pu\u00f2 sembrare pi\u00f9 accessibile ad utenti principianti e intermedi.<\/p>\n Di base, offre funzionalit\u00e0 di cache e compressione HTTP, ma manca di minimizzazione delle risorse e di ottimizzazione JavaScript con gli attributi Con oltre 1.000.000 installazioni attive, Autoptimize<\/a>\u00a0\u00e8 uno dei plugin gratuiti pi\u00f9 popolari per la minificazione.<\/p>\n Viene fornito con una pagina di opzioni suddivisa in diverse sezioni dove l’amministratore del sito pu\u00f2 configurare separatamente la minificazione di HTML, CSS e JavaScript.<\/p>\n \u00c8 anche possibile aggregare script o fogli di stile indipendenti e impostare eccezioni per risorse specifiche. Inoltre, Autoptimize permette di mettere in cache le risorse minificate su disco o su CDN e di salvare le risorse ottimizzate come file statici. Per trovare le migliori impostazioni per il vostro sito WordPress potete seguire la nostra guida dettagliata su Autoptimize<\/a>.<\/p>\n Altri plugin di ottimizzazione da provare:<\/p>\n Swift Performance<\/a> \u00e8 un altro plugin cui potreste dare un’occhiata. Si tratta di un plugin premium che pu\u00f2 aiutarvi ad aumentare i vostri punteggi di performance, ed \u00e8 stato sviluppato appositamente per aiutarvi a raggiungere quel famoso 100\/100 su Google PageSpeed Insights<\/a>.<\/p>\n Alcune delle sue funzionalit\u00e0 principali includono:<\/p>\n Troverete una descrizione pi\u00f9 approfondita dei plugin di ottimizzazione di WordPress in Come Eliminare JavaScript e CSS che Bloccano il Rendering<\/a>.<\/p>\n L’ottimizzazione del percorso di rendering critico \u00e8 un processo di miglioramento e misurazione che richiede una chiara comprensione di ogni task eseguito dal browser per convertire il codice in pixel e quindi per rendere una pagina sullo schermo. Potete saperne di pi\u00f9 sul Critical Rendering Path nella guida all’ottimizzazione di Google<\/a>.<\/p>\n Qui, sul blog di Kinsta, cerchiamo di analizzare tutti gli aspetti dell’ottimizzazione delle performance. Ecco un elenco di altre letture:<\/p>\n Quanto tempo vi occorre per ottimizzare il Percorso di Rendering Critico dei vostri siti web? E quali aspetti del processo di ottimizzazione sono i pi\u00f9 difficili da gestire? Scrivetecelo nei commenti qui sotto.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Il Critical Rendering Path o (Percorso di Rendering Critico) \u00e8 la sequenza di operazioni che il browser esegue per il primo rendering di una pagina sullo …<\/p>\n","protected":false},"author":36,"featured_media":33262,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[66,3],"topic":[25869,25873],"class_list":["post-33236","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-webperf","tag-wordpress","topic-prestazioni-wordpress","topic-sviluppo-wordpress"],"yoast_head":"\n\n
La Sequenza del Percorso di Rendering Critico<\/h2>\n
\n
Il DOM<\/h3>\n
\n
![\"Struttura](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/struttura-dom.png\")
Il CSSOM<\/h3>\n
link<\/code> che si riferisce ad un foglio di stile CSS esterno, blocca il parsing e invia una richiesta per questa risorsa. Una volta ricevuto il file CSS, il browser inizia a costruire una struttura dati ad albero dei nodi CSS.<\/p>\n\n
![\"Struttura](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/struttura-cssom.png\")
Il Render Tree<\/h3>\n
![\"Struttura](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/struttura-albero-render-tree.png\")
Layout e Resa a Video<\/h3>\n
Ottimizzazione del Percorso di Rendering Critico<\/h2>\n
\nUna delle raccomandazioni pi\u00f9 rilevanti di Google \u00e8 quella di dare priorit\u00e0 ai contenuti visibili, in modo da rendere il pi\u00f9 veloce possibile la parte Above the Fold e fornisce due regole principali da seguire:<\/p>\n\n
\nIl browser costruisce il DOM in modo\u00a0incrementale, e questo ci d\u00e0 l’opportunit\u00e0 di ridurre il tempo necessario per rendere l’ATF strutturando l’HTML in modo da caricare prima l’above the fold e rimandare il resto della pagina.<\/p>\n![\"Il](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/il-contenuto-above-fold-varia-seconda-dispositivo.png\")
Minimizzate le Dimensioni delle Risorse<\/h2>\n
\n
Ottimizzate i CSS<\/h2>\n
\nI CSS possono essere adattati a condizioni particolari, e possiamo ottimizzarli utilizzando i media type e le media query. Se state visualizzando una pagina web sullo schermo, il browser invier\u00e0 una richiesta per il media type di stampa, ma non bloccher\u00e0 il rendering della pagina per questa risorsa.
\nPrendete il seguente tag di link<\/code>:<\/p>\n<link rel=\"stylesheet\" href=\"style.css\" \/><\/code><\/pre>\n
\nFortunatamente, possiamo inviare una richiesta per una risorsa CSS a condizioni specifiche. Potremmo spostare gli stili per la stampa in un file separato e usare l’attributo media<\/code> per dire al browser che il foglio di stile specificato deve essere caricato solo quando si stampa la pagina, e non ha bisogno di bloccare il rendering sullo schermo:<\/p>\n<link rel=\"stylesheet\" href=\"print.css\" media=\"print\" \/><\/code><\/pre>\nlink<\/code>, in modo da poter dividere i CSS in pi\u00f9 file e caricarli in via condizionale:<\/p>\n<link rel=\"stylesheet\" href=\"style.css\" media=\"screen\" \/>\n<link rel=\"stylesheet\" href=\"portrait.css\" media=\"orientation:portrait\" \/>\n<link rel=\"stylesheet\" href=\"widescreen.css\" media=\"(min-width: 42rem)\" \/><\/code><\/pre>\n\n
Velocizzare i Processi di Layout e Resa a Video<\/h2>\n
\n
box-shadow<\/code>, che richiede qualche tipo di calcolo, richiederebbe pi\u00f9 tempo di un colore di bordo solido.<\/p>\n![\"Chrome](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/chrome-devtools-permette-identificare-pagina-vengono-1024x491.png\")
Evitare che JavaScript Blocchi il Rendering<\/h2>\n
\nDetto questo, cosa possiamo fare per ridurre al minimo il tempo impiegato dal browser per caricare ed eseguire JavaScript?<\/p>\n\n
async<\/code> del tag script<\/code> istruisce il browser ad eseguire lo script in modo asincrono, se possibile, senza bloccare la costruzione del DOM. Il browser invia la richiesta HTTP per lo script e continua il parsing del DOM. Inoltre, lo script non blocca la costruzione del CSSOM, il che significa che non bloccher\u00e0 il Critical Rendering Path (si veda la documentazione di MDN<\/a> per maggiori informazioni sugli attributi dei tag script<\/strong>)<\/li>\ndefer<\/code> del tag script<\/code> dice al browser di eseguire lo script dopo l’analisi del documento, ma prima di avviare l’evento DOMContentLoaded<\/code>. Questo attributo non deve essere usato se l’attributo src \u00e8 assente, cio\u00e8 negli script in linea (per saperne di pi\u00f9, si legga Mozilla Hacks<\/a>)<\/li>\nasync<\/code> e defer<\/code> per gli script in linea, quindi l’unico modo per caricarli dopo che il documento \u00e8 stato caricato \u00e8 spostarli in basso. Il vantaggio \u00e8 che gli script in linea non richiedono altre richieste HTTP. Tuttavia, inserire gli script in linea quando questi sono utilizzati in diverse pagine sarebbe ridondante.<\/li>\n<\/ul>\nRiepilodo delle Regole di Ottimizzazione<\/h2>\n
\n
\n
link<\/code><\/li>\n\n
defer<\/code> sui tag script<\/li>\nasync<\/code> sui tag script<\/li>\nscript<\/code> in fondo al documento<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nOttimizzare il Critical Rendering Path in WordPress<\/h2>\n
W3 Total Cache<\/h3>\n
![\"W3](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/w3-totale-cache-wordpress-plugin-it.jpg\")
<\/a>\n
async<\/code> e defer<\/code><\/li>\n![\"Impostazioni](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/w3-total-cache-javascript-minify-impostazioni.png\")
WP Super Cache<\/h3>\n
![\"Il](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/wp-super-cache-wordpress-plugin-it.png\")
<\/a>![\"WordPress](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/worpress-super-cache-tester.png\")
async<\/code> e defer<\/code>. Tuttavia, pi\u00f9 di un milione di installazioni attive dimostrano che il plugin merita di essere provato.<\/p>\n![\"Opzione](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/opzione-gzip-wp-super-cache-it.png\")
Autoptimize<\/h3>\n
![\"Il](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/autoptimizzare-plugin-wordpress.jpg\")
<\/a>![\"Opzione](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/opzione-ottimizzazione-automatica-html.png\")
\n
Swift Performance<\/h3>\n
![\"Il](\"https:\/\/kinsta.com\/it\/wp-content\/uploads\/sites\/2\/2017\/11\/swift-performance-wordpress-plugin-it.png\")
<\/a>\n
Conclusioni<\/h2>\n
\n