Il primo passaggio per creare un sito web che si carica rapidamente consiste nel ricevere una risposta tempestiva dal server al codice HTML di una pagina. Quando inserisci un URL nella barra degli indirizzi del browser, il browser invia una richiesta GET al server per recuperarla. La prima richiesta di una pagina web riguarda una risorsa HTML: un obiettivo chiave è garantire che il codice HTML arrivi rapidamente con minimi ritardi.
La richiesta iniziale di HTML passa attraverso diversi passaggi, ognuno dei quali richiede un po' di tempo. La riduzione del tempo speso su ogni passaggio consente di ottenere un tempo per il primo byte (TTFB) più rapido. Anche se la TTFB non è l'unica metrica su cui dovresti concentrarti per quanto riguarda la velocità di caricamento delle pagine, un TTFB elevato compie difficoltà a raggiungere le soglie indicate "buone" 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, con un reindirizzamento permanente (una risposta 301 Moved Permanently) o uno temporaneo (una 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 della 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 server web.
- Reindirizzamenti multiorigine avviati da un'altra origine. Questi tipi di reindirizzamenti sono generalmente fuori dal tuo controllo.
I reindirizzamenti multiorigine vengono spesso utilizzati da annunci, servizi di accorciamento di URL e altri servizi di terze parti. Sebbene i reindirizzamenti multiorigine non siano sotto il tuo controllo, ti consigliamo di verificare di evitare più reindirizzamenti, ad esempio creare un annuncio che rimanda a una pagina HTTP che a sua volta reindirizza al suo equivalente HTTPS oppure un reindirizzamento multiorigine che arriva alla tua origine, ma attiva un reindirizzamento dalla stessa origine.
Memorizza nella cache le risposte HTML
Memorizzare nella cache le risposte HTML è complicato, 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 digitale univoca nei rispettivi nomi file, che cambia in base ai contenuti dei file. Ciò significa che il documento HTML memorizzato nella cache potrebbe diventare inattivo dopo un deployment, poiché conterrebbe riferimenti a sottorisorse obsolete.
Ciononostante, una breve durata della cache, anziché l'assenza della memorizzazione nella cache, può offrire vantaggi come la memorizzazione nella cache di una risorsa su una rete CDN, la riduzione del numero di richieste inviate dal server di origine e nel browser, la possibilità di riconvalidare le risorse invece di scaricarle di nuovo. Questo approccio funziona meglio per i contenuti statici che non cambiano in nessun contesto. Puoi impostare un tempo appropriato per memorizzare le risorse nella cache sul numero di minuti che riterrai opportuno. Cinque minuti per le risorse HTML statiche sono una scommessa sicura e garantisce 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 probabile che tu non voglia memorizzare i contenuti nella cache per vari problemi, tra cui sicurezza e aggiornamento. Se una risposta HTML viene memorizzata nella cache dal browser dell'utente, non puoi invalidarla. Pertanto, in questi casi è preferibile evitare del tutto la memorizzazione nella cache dell'HTML.
Un approccio prudente alla memorizzazione nella cache dell'HTML potrebbe essere l'utilizzo delle intestazioni di risposta ETag o Last-Modified. Un'intestazione ETag, altrimenti nota 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 viene modificata, è necessario generare un nuovo valore ETag. Nelle richieste successive, il browser invia il valore ETag tramite l'intestazione della richiesta If-None-Match. Se ETag sul server corrisponde a quello
inviato dal browser, il server risponde con una risposta 304 Not Modified
e il browser utilizza la risorsa della cache. Anche se ciò comporta 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 riconvalida dell'aggiornamento di una risorsa è ancora un aspetto negativo. Come per molti altri aspetti dello sviluppo web, i compromessi e le compromissioni sono inevitabili. Sta a te capire se vale la pena di memorizzare nella cache l'HTML in questo modo o se è meglio restare al sicuro e non occuparti affatto di contenuti HTML memorizzati nella cache.
Misura i tempi di risposta del server
Se la risposta non viene memorizzata nella cache, il tempo di risposta del server dipende in modo significativo dal provider host e dallo stack delle applicazioni di backend. Una pagina web che fornisce una risposta generata dinamicamente, ad esempio il recupero dei dati da un database, potrebbe avere un TTFB maggiore rispetto a una pagina web statica che può essere pubblicata immediatamente senza tempi di calcolo significativi sul backend. La visualizzazione di uno spinner di caricamento e il recupero di tutti i dati sul lato client spostano l'impegno da un ambiente lato server più prevedibile a uno lato client potenzialmente imprevedibile. Ridurre al minimo l'impegno lato client di solito porta al miglioramento delle metriche incentrate sull'utente.
Se gli utenti riscontrano un TTFB lento nel campo, puoi esporre informazioni sulla posizione in cui il tempo è stato trascorso 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, oltre a una
durata per ognuna. Questi dati possono essere poi raccolti dagli utenti sul campo utilizzando l'API Navigation Timing e analizzati per verificare se gli utenti stanno riscontrando ritardi. Nello snippet di codice precedente, l'intestazione della risposta include due tempistiche:
- Il tempo per autenticare un utente (
auth), che ha richiesto 55,5 millisecondi. - Il tempo di accesso al database (
db), che ha richiesto 220 millisecondi.
Ti consigliamo inoltre di rivedere 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 offrono 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 di trasferimento sulla rete in modo da essere scaricate più rapidamente. Gli algoritmi di compressione più utilizzati sono gzip e Brotli. Brotli migliora tra il 15% e il 20% circa rispetto a gzip.
La compressione viene spesso impostata automaticamente dalla maggior parte dei provider di hosting web, ma ci sono alcuni aspetti importanti da considerare se sei in grado 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. Se possibile, utilizza Brotli, ma se il tuo sito web è utilizzato da un numero elevato di utenti su browser legacy, assicurati di utilizzare gzip come metodo di riserva, in quanto qualsiasi compressione è meglio di nessuna compressione.
- Le dimensioni dei file sono importanti. Le risorse molto piccole (meno di 1 KiB) non si comprimono molto bene o, a volte, non si comprimono affatto. L'efficacia di qualsiasi tipo di compressione dei dati dipende dalla presenza di una grande quantità di dati con cui un algoritmo di compressione può lavorare per trovare bit di dati più comprimibili. Più un file è grande, migliore è la compressione, ma non inviare risorse molto grandi, semplicemente perché possono essere compresse in modo più efficace. Le risorse di grandi dimensioni, come ad esempio JavaScript e CSS, richiedono molto più tempo per analizzarle e valutarle dopo che il browser le ha decompresse e potrebbero cambiare più spesso anche se sono state modificate solo marginalmente, in quanto eventuali modifiche generano un hash del file diverso.
- Comprendi la differenza tra la compressione dinamica e statica. La compressione dinamica e statica sono approcci diversi a 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. Al contrario, la compressione statica comprime i file in anticipo, impedendo l'esecuzione della compressione al momento della richiesta. La compressione statica rimuove la latenza coinvolta nella compressione stessa, che può aumentare i tempi di risposta del server in caso di compressione dinamica. Le risorse statiche, come le immagini JavaScript, CSS e SVG, devono essere compresse in modo statico, mentre le risorse HTML, soprattutto se sono generate dinamicamente per utenti autenticati, devono essere compresse in modo dinamico.
Ottenere la compressione autonomamente è difficile e spesso è meglio lasciare che una rete CDN (Content Delivery Network), di cui parleremo nella sezione successiva, se ne occuperà per te. Questi concetti, però, possono aiutarti a capire se il tuo provider host utilizza correttamente la compressione. Queste informazioni possono aiutarti a trovare opportunità per migliorare le impostazioni di compressione in modo che generino il massimo vantaggio per il tuo sito web.
Reti CDN (Content Delivery Network)
Una rete CDN (Content Delivery Network) è una rete distribuita di server che memorizza nella cache le risorse del tuo server di origine e, a loro volta, le fornisce da server perimetrali fisicamente più vicini ai tuoi utenti. La vicinanza fisica agli utenti riduce il tempo di round trip (RTT), mentre le 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 accadrebbe 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
Che 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 ai tuoi utenti finali?
A seguire: comprensione del percorso critico
Ora che hai acquisito familiarità con alcune considerazioni sulle prestazioni relative al codice HTML del tuo sito web, sei in una posizione migliore per fare in modo che il sito venga caricato il più rapidamente possibile, ma questo è solo l'inizio della procedura per apprendere il rendimento sul web. Successivamente, viene illustrata la teoria alla base del percorso di rendering critico. Questo modulo descrive i concetti chiave quali le risorse di blocco della visualizzazione e dell'analisi, nonché il ruolo che svolgono per ottenere il rendering iniziale di una pagina nel browser il più rapidamente possibile.