Il primo passo per creare un sito web che si carichi rapidamente è ricevere una risposta tempestiva
dal server per l'HTML di una pagina. Quando inserisci un URL nella barra degli indirizzi del browser, quest'ultimo invia una richiesta GET al server per recuperarlo. La prima richiesta di una pagina web riguarda una risorsa HTML e
garantire che l'HTML arrivi rapidamente con ritardi minimi è un obiettivo
di rendimento fondamentale.
La richiesta iniziale di HTML passa attraverso diverse fasi, ognuna delle quali richiede un po' di tempo. Ridurre il tempo dedicato a ogni passaggio ti consente di ottenere un Time to First Byte (TTFB) più rapido. Sebbene il TTFB non sia l'unica metrica su cui concentrarsi quando si tratta della velocità di caricamento delle pagine, un TTFB elevato rende difficile raggiungere le soglie "buone" designate per metriche come Largest Contentful Paint (LCP) e First Contentful Paint (FCP).
Riduci al minimo i reindirizzamenti
Quando viene richiesta una risorsa, il server può rispondere con un reindirizzamento, permanente (risposta 301 Moved Permanently) o temporaneo (risposta 302 Found).
I reindirizzamenti rallentano la velocità di caricamento della pagina perché richiedono al browser di effettuare una richiesta HTTP aggiuntiva nella nuova posizione per recuperare la risorsa. Esistono due tipi di reindirizzamenti:
- Reindirizzamenti con stessa origine che si verificano interamente all'interno della tua origine. Questi tipi di reindirizzamenti sono completamente sotto il tuo controllo, poiché la logica per la loro gestione risiede interamente sul tuo web server.
- Reindirizzamenti multiorigine avviati da un'altra origine. Questi tipi di reindirizzamenti in genere non sono sotto il tuo controllo.
I reindirizzamenti multiorigine vengono spesso utilizzati da annunci, servizi di accorciamento degli URL e altri servizi di terze parti. Sebbene i reindirizzamenti cross-origin non siano sotto il tuo controllo, ti consigliamo comunque di evitare reindirizzamenti multipli, ad esempio un annuncio che rimanda a una pagina HTTP che a sua volta reindirizza alla pagina HTTPS equivalente o un reindirizzamento cross-origin che arriva alla tua origine, ma poi attiva un reindirizzamento same-origin.
Memorizzare nella cache le risposte HTML
La memorizzazione nella cache delle risposte HTML è difficile, poiché la risposta potrebbe includere link ad altre risorse critiche come CSS, JavaScript, immagini e altri tipi di risorse. Queste risorse possono includere un'impronta univoca nei rispettivi nomi file, che cambia in base ai contenuti di un file. Ciò significa che il documento HTML memorizzato nella cache potrebbe diventare obsoleto dopo un deployment, in quanto conterrebbe riferimenti a risorse secondarie obsolete.
Tuttavia, una durata della cache breve, anziché nessuna memorizzazione nella cache, può avere vantaggi come consentire a una risorsa di essere memorizzata nella cache di una CDN, riducendo il numero di richieste gestite dal server di origine, e nel browser, consentendo la convalida delle risorse anziché il loro nuovo download. Questo approccio funziona meglio per i contenuti statici che non cambiano in nessun contesto e un tempo appropriato per memorizzare nella cache le risorse può essere impostato su un numero di minuti che ritieni appropriato. Cinque minuti per le risorse HTML statiche sono un'opzione sicura e garantiscono che gli aggiornamenti periodici non passino inosservati.
Se i contenuti HTML di una pagina sono personalizzati in qualche modo, ad esempio per un utente autenticato, molto probabilmente non vuoi memorizzare nella cache i contenuti per una serie di motivi, tra cui sicurezza e aggiornamento. Se una risposta HTML viene memorizzata nella cache dal browser dell'utente, non puoi invalidare la cache. Pertanto, in questi casi è meglio evitare del tutto la memorizzazione nella cache dell'HTML.
Un approccio cauto alla memorizzazione nella cache dell'HTML potrebbe essere quello di utilizzare le intestazioni della risposta ETag o Last-Modified. Un'intestazione ETag, nota anche come tag di entità, è un identificatore che rappresenta in modo univoco la risorsa richiesta, spesso utilizzando un hash dei contenuti della risorsa:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Ogni volta che la risorsa cambia, deve essere generato un nuovo valore ETag. Nelle
richieste successive, il browser invia il valore ETag tramite
l'intestazione della richiesta If-None-Match. Se il valore ETag sul server corrisponde a quello inviato dal browser, il server risponde con una risposta 304 Not Modified e il browser utilizza la risorsa dalla cache. Sebbene ciò comporti comunque
una latenza di rete, una risposta 304 Not Modified è molto più piccola di un'intera
risorsa HTML.
Tuttavia, la latenza di rete coinvolta nella convalida della freschezza di una risorsa è comunque un tipo di svantaggio. Come per molti altri aspetti dello sviluppo web, i compromessi sono inevitabili. Spetta a te decidere se lo sforzo aggiuntivo per memorizzare nella cache l'HTML in questo modo vale la pena o se è meglio non memorizzare nella cache i contenuti HTML.
Misurare i tempi di risposta del server
Se una risposta non viene memorizzata nella cache, il tempo di risposta del server dipende in larga misura dal provider di hosting e dallo stack di applicazioni di backend. Una pagina web che fornisce una risposta generata dinamicamente, ad esempio recuperando dati da un database, potrebbe avere un TTFB più elevato rispetto a una pagina web statica che può essere pubblicata immediatamente senza un tempo di calcolo significativo nel backend. La visualizzazione di un indicatore di caricamento e il recupero di tutti i dati sul lato client sposta l'impegno da un ambiente lato server più prevedibile a uno lato client potenzialmente imprevedibile. La riduzione dello sforzo lato client di solito comporta un miglioramento delle metriche incentrate sull'utente.
Se gli utenti riscontrano un TTFB lento sul campo, puoi esporre informazioni
su dove è stato impiegato il tempo sul server utilizzando l'intestazione della risposta
Server-Timing:
Server-Timing: auth;dur=55.5, db;dur=220
Il valore di un'intestazione Server-Timing può includere più metriche, nonché una durata per ciascuna. Questi dati possono poi essere raccolti dagli utenti sul campo
utilizzando l'API Navigation Timing e analizzati per verificare se gli utenti riscontrano
ritardi. Nello snippet di codice precedente, l'intestazione della risposta include due tempistiche:
- Il tempo necessario per autenticare un utente (
auth), pari a 55,5 millisecondi. - Il tempo di accesso al database (
db), che ha richiesto 220 millisecondi.
Ti consigliamo inoltre di esaminare la tua infrastruttura di hosting e verificare di disporre di risorse adeguate per gestire il traffico ricevuto dal tuo sito web. I provider di hosting condiviso sono spesso soggetti a un TTFB elevato e le soluzioni dedicate che forniscono tempi di risposta più rapidi possono essere più costose.
Compressione
Le risposte basate su testo, come immagini HTML, JavaScript, CSS e SVG, devono essere compresse per ridurre le dimensioni del trasferimento sulla rete in modo che vengano scaricate più rapidamente. Gli algoritmi di compressione più utilizzati sono gzip e Brotli. Brotli comporta un miglioramento di circa il 15-20% rispetto a gzip.
La compressione viene spesso configurata automaticamente dalla maggior parte dei provider di hosting web, ma ci sono alcune cose importanti da considerare se hai la possibilità di configurare o modificare personalmente le impostazioni di compressione:
- Se possibile, utilizza Brotli. Come indicato in precedenza, Brotli offre un miglioramento abbastanza evidente rispetto a gzip e Brotli è supportato in tutti i principali browser. Utilizza Brotli quando possibile, ma se il tuo sito web viene utilizzato da un numero elevato di utenti su browser legacy, assicurati che Gzip venga utilizzato come fallback, in quanto qualsiasi compressione è meglio di nessuna compressione.
- Le dimensioni del file sono importanti. Le risorse molto piccole, inferiori a 1 KiB, non vengono compresse molto bene o a volte non vengono compresse affatto. L'efficacia di qualsiasi tipo di compressione dei dati dipende dalla disponibilità di una grande quantità di dati con cui un algoritmo di compressione può lavorare per trovare bit di dati più comprimibili. Maggiore è la dimensione di un file, migliore è la compressione. Tuttavia, non inviare risorse molto grandi solo perché possono essere compresse in modo più efficace. Le risorse di grandi dimensioni, come JavaScript e CSS, ad esempio, richiedono molto più tempo per l'analisi e la valutazione dopo che il browser le ha decompresse e potrebbero cambiare più frequentemente anche se sono cambiate solo marginalmente, poiché qualsiasi modifica comporta un hash del file diverso.
- Comprendere la compressione dinamica e statica. La compressione dinamica e statica sono approcci diversi per quando una risorsa deve essere compressa. La compressione dinamica comprime una risorsa nel momento in cui viene richiesta e a volte ogni volta che viene richiesta. D'altra parte, la compressione statica comprime i file in anticipo, senza richiedere alcuna compressione al momento della richiesta. La compressione statica elimina la latenza coinvolta nella compressione stessa, che può aumentare i tempi di risposta del server nel caso della compressione dinamica. Le risorse statiche, come JavaScript, CSS e immagini SVG, devono essere compresse staticamente, mentre le risorse HTML, soprattutto se vengono generate dinamicamente per gli utenti autenticati, devono essere compresse dinamicamente.
Eseguire la compressione in autonomia è difficile e spesso è meglio lasciare che se ne occupi una rete CDN (Content Delivery Network), argomento trattato nella sezione successiva. Tuttavia, conoscere questi concetti può aiutarti a capire se il tuo provider di hosting utilizza correttamente la compressione. Queste informazioni possono aiutarti a trovare opportunità per migliorare le impostazioni di compressione in modo che offrano il massimo vantaggio per il tuo sito web.
Reti CDN (Content Delivery Network)
Una Content Delivery Network (CDN) è una rete distribuita di server che memorizzano nella cache le risorse del server di origine e, a loro volta, le pubblicano da server perimetrali fisicamente più vicini agli utenti. La vicinanza fisica agli utenti riduce il round-trip time (RTT), mentre ottimizzazioni come HTTP/2 o HTTP/3, la memorizzazione nella cache e la compressione consentono alla CDN di pubblicare i contenuti più rapidamente rispetto a quanto avverrebbe se venissero recuperati dal server di origine. L'utilizzo di una CDN può migliorare significativamente il TTFB del tuo sito web in alcuni casi.
Verifica le tue conoscenze
Quale tipo di reindirizzamento è completamente sotto il tuo controllo?
L'intestazione Server-Timing può contenere più metriche.
Quale tipo di server ha maggiori probabilità di trovarsi fisicamente più vicino agli utenti finali?
Prossimo argomento: comprendere il percorso critico
Ora che hai familiarità con alcune delle considerazioni sul rendimento relative all'HTML del tuo sito web, sei in una posizione migliore per assicurarti che possa caricarsi il più rapidamente possibile, ma questo è solo l'inizio dell'apprendimento del rendimento del web. Successivamente, viene illustrata la teoria alla base del percorso di rendering critico. Questo modulo descrive concetti chiave come le risorse di blocco del rendering e dell'analisi e il ruolo che svolgono nell'ottenere il rendering iniziale di una pagina nel browser il più rapidamente possibile.