Ottimizzazione delle prestazioni del sito Web e del percorso di rendering critico

Le prestazioni di rendering della tua pagina web soddisfano gli standard odierni? Il rendering è il processo di traduzione della risposta di un server nell'immagine che il browser "dipinge" quando un utente visita un sito web. Una cattiva prestazione di rendering può tradursi in una frequenza di rimbalzo relativamente alta.

Esistono diverse risposte del server che determinano se una pagina viene visualizzata o meno. In questo articolo, ci concentreremo sul rendering iniziale della pagina Web, che inizia con l'analisi dell'HTML (a condizione che il browser abbia ricevuto correttamente l'HTML come risposta del server). Esploreremo le cose che possono portare a tempi di rendering elevati e come risolverli.

Percorso di rendering critico

Il percorso di rendering critico (CRP) è il processo che il tuo browser esegue per convertire il codice in pixel visualizzabili sullo schermo. Ha diverse fasi, alcune delle quali potrebbero essere eseguite in parallelo per risparmiare tempo, ma alcune parti devono essere eseguite di conseguenza. Qui viene visualizzato:

Prima di tutto, una volta che il browser riceve la risposta, inizia ad analizzarla. Quando incontra una dipendenza, prova a scaricarla.

Se si tratta di un foglio di stile, il browser dovrà analizzarlo completamente prima di eseguire il rendering della pagina, ed è per questo che si dice che CSS blocchi il rendering .

Se si tratta di uno script, il browser deve: interrompere l'analisi, scaricare lo script ed eseguirlo. Solo dopo può continuare l'analisi, perché i programmi JavaScript possono alterare il contenuto di una pagina web (HTML, in particolare). Ed è per questo che JS è chiamato blocco del parser .

Una volta completata l'analisi, il browser ha il Document Object Model (DOM) e il Cascading Style Sheets Object Model (CSSOM). Combinandoli insieme si ottiene l'albero di rendering. Le parti non visualizzate della pagina non entrano nell'albero di rendering, perché contiene solo i dati necessari per disegnare la pagina.

Il penultimo passaggio è tradurre l'albero di rendering in layout. Questa fase è anche chiamata Reflow. È qui che viene calcolata ogni posizione di ogni nodo di Render Tree, così come le sue dimensioni.

Infine, l'ultimo passaggio è Paint. Implica letteralmente la colorazione dei pixel in base ai dati che il browser ha calcolato durante le fasi precedenti.

Conclusioni relative all'ottimizzazione

Come puoi immaginare, il processo di ottimizzazione delle prestazioni del sito Web comporta modifiche al sito Web che riducono:

• La quantità di dati che deve essere trasferita
• Il numero di risorse che il browser deve scaricare (soprattutto quelle bloccanti)
• La lunghezza di CRP

Inoltre, ci addentreremo nei dettagli di come è fatto, ma prima c'è una regola importante da osservare.

Come misurare le prestazioni

Un'importante regola di ottimizzazione è: misurare prima, ottimizzare secondo necessità . La maggior parte degli strumenti per sviluppatori dei browser dispone di una scheda denominata Prestazioni ed è qui che si verificano le misurazioni. Quando si ottimizza per il (primo) rendering iniziale più veloce, la cosa più importante da considerare è l'ora dei seguenti eventi:

• Prima vernice
• Prima pittura contenta
• La prima pittura significativa

Qui, "Paint" significa rendering riuscito di una pagina, l'ultima fase nel percorso di rendering critico. Alcuni rendering possono verificarsi uno dopo l'altro perché i browser cercano di visualizzare qualcosa il prima possibile e di aggiornarli in un secondo momento.

Oltre al tempo di rendering, ci sono altre cose da tenere in considerazione, soprattutto quante risorse di blocco vengono utilizzate e quanto tempo ci vuole per scaricarle. Queste informazioni si trovano nella scheda Prestazioni dopo aver effettuato le misurazioni.

Strategie di ottimizzazione delle prestazioni

Dato ciò che abbiamo appreso sopra, ci sono tre strategie principali per l'ottimizzazione delle prestazioni del sito web:

1. Ridurre al minimo la quantità di dati da trasferire via cavo,
2. Ridurre il numero totale di risorse da trasferire via cavo e
3. Accorciare il percorso di rendering critico

1. Ridurre al minimo la quantità di dati da trasferire

Prima di tutto, rimuovi tutte le parti non utilizzate, come le funzioni irraggiungibili in JavaScript, gli stili con selettori che non corrispondono mai a nessun elemento e i tag HTML che sono nascosti per sempre con CSS. In secondo luogo, rimuovi tutti i duplicati.

Quindi, ti consiglio di mettere in atto un processo automatico di minimizzazione. Ad esempio, dovrebbe rimuovere tutti i commenti da ciò che il tuo back-end sta servendo (ma non il codice sorgente) e ogni carattere che non contiene informazioni aggiuntive (come gli spazi bianchi in JS).

Dopo che ciò è stato fatto, ciò che ci rimane può essere come testo. Significa che possiamo applicare in sicurezza un algoritmo di compressione come GZIP (che la maggior parte dei browser comprende).

Infine, c'è la memorizzazione nella cache. Non aiuterà la prima volta che un browser esegue il rendering della pagina, ma farà risparmiare molto nelle visite successive. Tuttavia, è fondamentale tenere a mente due cose:

• Se utilizzi una CDN, assicurati che la memorizzazione nella cache sia supportata e impostata correttamente.
• Invece di aspettare che arrivi la data di scadenza delle risorse, potresti voler avere un modo per aggiornarlo prima dalla tua parte. Incorpora le "impronte digitali" dei file nei loro URL per poter invalidare la cache locale.

Naturalmente, le politiche di memorizzazione nella cache dovrebbero essere definite per risorsa. Alcuni potrebbero cambiare raramente o non cambiare mai. Altri stanno cambiando più velocemente. Alcuni contengono informazioni sensibili, altri potrebbero essere considerati pubblici. Utilizzare la direttiva "private" per impedire alle CDN di memorizzare nella cache i dati privati.

È anche possibile ottimizzare le immagini Web, sebbene le richieste di immagini non blocchino né l'analisi né il rendering.

2. Ridurre il conteggio totale delle risorse critiche

"Critico" si riferisce solo alle risorse necessarie per il corretto rendering della pagina Web. Pertanto, possiamo saltare tutti gli stili che non sono coinvolti direttamente nel processo. E anche tutti gli script.

Fogli di stile

Per dire al browser che non sono richiesti particolari file CSS, dovremmo impostare gli attributi media su tutti i collegamenti che fanno riferimento ai fogli di stile. Con questo approccio, il browser tratterà solo le risorse che corrispondono al media corrente (tipo di dispositivo, dimensioni dello schermo) come necessario, abbassando la priorità di tutti gli altri fogli di stile (verranno comunque elaborati, ma non come parte del rendering critico sentiero). Ad esempio, se aggiungi l'attributo media="print" al tag di style che fa riferimento agli stili per la stampa della pagina, questi stili non interferiranno con il tuo percorso di rendering critico quando il supporto non viene print (ad esempio, quando visualizzi il pagina in un browser).

Per migliorare ulteriormente il processo, puoi anche creare alcuni stili in linea. Questo ci fa risparmiare almeno un viaggio di andata e ritorno al server che sarebbe stato altrimenti richiesto per ottenere il foglio di stile.

Script

Come accennato in precedenza, gli script bloccano il parser perché possono alterare DOM e CSSOM. Pertanto, gli script che non li alterano non dovrebbero bloccare l'analisi, risparmiandoci così tempo.

Per implementarlo, tutti i tag di script devono essere contrassegnati con attributi, async o defer .

Gli script contrassegnati con async non bloccano la costruzione DOM o CSSOM, poiché possono essere eseguiti prima della compilazione di CSSOM. Tieni presente, tuttavia, che gli script inline bloccheranno comunque CSSOM a meno che non li metti sopra CSS.

Al contrario, gli script contrassegnati con defer verranno valutati al termine del caricamento della pagina. Pertanto, non dovrebbero influire sul documento (altrimenti, verrà attivato un nuovo rendering).

In altre parole, con defer , lo script non viene eseguito fino a dopo l'attivazione dell'evento di caricamento della pagina, mentre async consente di eseguire lo script in background durante l'analisi del documento.

3. Ridurre la lunghezza del percorso di rendering critico

Infine, la lunghezza del CRP dovrebbe essere ridotta al minimo possibile. In parte, gli approcci sopra descritti lo faranno.

Le media query come attributi per i tag di stile ridurranno il conteggio totale delle risorse che devono essere scaricate. Gli attributi del tag script defer e async impediranno agli script corrispondenti di bloccare l'analisi.

La minimizzazione, la compressione e l'archiviazione delle risorse con GZIP ridurranno le dimensioni dei dati trasferiti (riducendo così anche il tempo di trasferimento dei dati).

L'integrazione di alcuni stili e script può ridurre il numero di viaggi di andata e ritorno tra il browser e il server.

Quello che non abbiamo ancora discusso è l'opzione per riorganizzare il codice tra i file. Secondo l'ultima idea di migliori prestazioni, la prima cosa che un sito web dovrebbe fare più velocemente è visualizzare il contenuto ATF. ATF sta per above the fold. Questa è l'area immediatamente visibile, senza scorrere. Pertanto, è meglio riorganizzare tutto ciò che riguarda il rendering in modo che gli stili e gli script richiesti vengano caricati prima, con tutto il resto che si interrompe, né l'analisi né il rendering. E ricorda sempre di misurare prima e dopo aver apportato la modifica.

Conclusione: l'ottimizzazione comprende l'intero stack

In sintesi, l'ottimizzazione delle prestazioni del sito Web incorpora tutti gli aspetti della risposta del sito, come la memorizzazione nella cache, l'impostazione di una CDN, il refactoring, l'ottimizzazione delle risorse e altri, tuttavia tutto ciò può essere eseguito gradualmente. In qualità di sviluppatore web, dovresti utilizzare questo articolo come riferimento e ricordarti sempre di misurare le prestazioni prima e dopo i tuoi esperimenti.

Gli sviluppatori di browser fanno del loro meglio per ottimizzare le prestazioni del sito Web per ogni pagina visitata, motivo per cui i browser di solito implementano il cosiddetto "pre-loader". Questa parte dei programmi esegue la scansione prima di una risorsa che hai richiesto in HTML per effettuare più richieste alla volta e farle funzionare in parallelo. Questo è il motivo per cui è meglio mantenere i tag di stile vicini l'uno all'altro in HTML (a livello di riga), così come i tag di script.

Inoltre, prova a raggruppare gli aggiornamenti in HTML per evitare più eventi di layout, che vengono attivati ​​non solo da una modifica in DOM o CSSOM, ma anche da una modifica dell'orientamento del dispositivo e da un ridimensionamento della finestra.

Risorse utili e ulteriori letture:

• Approfondimenti sulla velocità della pagina
• Lista di controllo per la memorizzazione nella cache
• Un modo per verificare se GZIP è abilitato per il tuo sito web
• Reti di browser ad alte prestazioni: un libro di Ilya Grigorik