Il primo passo per creare un sito web che si carichi rapidamente è ricevere una notifica
risposta dal server per il codice HTML di una pagina. Quando inserisci un URL nella sezione
barra degli indirizzi del browser, quest'ultimo invia una richiesta GET al server a
recuperarlo. La prima richiesta di una pagina web riguarda una risorsa HTML.
garantire che il codice HTML arrivi rapidamente con ritardi minimi è un'esecuzione chiave
obiettivo.
La richiesta iniziale di codice HTML passa attraverso diversi passaggi, ognuno dei quali prende per un po' di tempo. Se riduci il tempo dedicato a ogni passaggio, il tempo necessario per Primo byte (TTFB). Sebbene il TTFB non sia l'unica metrica su cui devi concentrarti quando per quanto riguarda la velocità di caricamento delle pagine, un valore TTFB elevato rende difficile la copertura designati come "beni" soglie 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 un
uno (una risposta 302 Found).
I reindirizzamenti rallentano la velocità di caricamento della pagina perché richiedono al browser di effettuare una richiesta HTTP aggiuntiva alla 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 dei reindirizzamenti è completamente sotto il tuo controllo, poiché la logica per la gestione che risiedono interamente sul tuo server web.
- Reindirizzamenti multiorigine avviati da un'altra origine. Questi tipi di i reindirizzamenti sono generalmente fuori dal tuo controllo.
I reindirizzamenti multiorigine vengono spesso utilizzati da annunci, servizi di abbreviazione di URL e altri servizi di terze parti. Sebbene i reindirizzamenti multiorigine siano al di fuori del tuo controllo, puoi comunque verificare di evitare più reindirizzamenti, ad esempio avere un annuncio che si collega a una pagina HTTP che a sua volta reindirizza al suo equivalente o un reindirizzamento multiorigine che arriva alla tua origine, ma poi attiva un reindirizzamento della stessa origine.
Memorizzazione nella cache delle risposte HTML
Memorizzare nella cache le risposte HTML è difficile, poiché la risposta può includere link a ad altre risorse fondamentali come CSS, JavaScript, immagini e altre risorse di testo. Queste risorse possono includere un fingerprint univoco nei loro rispettivi elenchi , che cambiano in base ai contenuti di un file. Ciò significa che i dati Il documento HTML potrebbe diventare inattivo in seguito a un deployment, in quanto conterrebbe a risorse secondarie obsolete.
Tuttavia, una breve durata della cache, anziché nessuna memorizzazione nella cache, può avere dei vantaggi ad esempio consentendo la memorizzazione nella cache di una risorsa su una CDN, riducendo il numero provenienti dal server di origine e nel browser, consentendo risorse da riconvalidare anziché scaricarle di nuovo. Questo approccio funziona ideale per i contenuti statici che non cambiano in nessun contesto e una per memorizzare nella cache le risorse possono essere impostate su un determinato numero di minuti appropriato. Cinque minuti per l'utilizzo di risorse HTML statiche sono una scommessa sicura e assicura che gli aggiornamenti periodici non passano inosservati.
Se i contenuti HTML di una pagina sono personalizzati in qualche modo, ad esempio per utente autenticato: probabilmente non vorrai memorizzare contenuti nella cache per una serie di problemi, tra cui e l'aggiornamento. Se una risposta HTML viene memorizzati nella cache dal browser dell'utente, non puoi invalidarla. È quindi meglio evitare del tutto la memorizzazione nella cache dell'HTML in questi casi.
Un approccio cautelativo alla memorizzazione nella cache dell'HTML potrebbe essere l'utilizzo della classe ETag o
Last-Modified intestazioni di risposta. Un'ETag, altrimenti nota come entità
: l'intestazione è 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, è necessario generare un nuovo valore ETag. Attivato
richieste successive, il browser invia il valore ETag tramite
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 questo comporta
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 è ma ha comunque un suo lato negativo. Come per molti altri aspetti dello sviluppo web, compromessi e compromissioni sono inevitabili. Sta a te capire se l'attività di memorizzare nella cache l'HTML in questo modo, o se è meglio per stare al sicuro e non preoccuparsi affatto della memorizzazione nella cache dei contenuti HTML.
Misurare i tempi di risposta del server
Se una risposta non viene memorizzata nella cache, il tempo di risposta del server dipende molto da quanto il provider host e lo stack delle applicazioni di backend. Una pagina web che pubblica una risposta generata dinamicamente, ad esempio recuperando i dati da un database, potrebbe avere un TTFB più alto di una pagina web statica che può essere pubblicata senza tempi di calcolo significativi sul backend. La visualizzazione di un la rotellina di caricamento e poi il recupero di tutti i dati sul lato client sposta lo sforzo da un ambiente lato server più prevedibile a un ambiente sul lato client. Ridurre al minimo lo sforzo lato client di solito si traduce in un miglioramento metriche incentrate sugli utenti.
Se gli utenti riscontrano una TTFB lenta sul campo, puoi esporre le informazioni
su dove è stato trascorso il tempo sul server grazie all'uso del Server-Timing
intestazione della risposta:
Server-Timing: auth;dur=55.5, db;dur=220
Il valore di un'intestazione Server-Timing può includere più metriche, nonché un
durata di ciascuna. Questi dati possono quindi essere raccolti dagli utenti sul campo
usando l'API Navigation Timing e vengono analizzati per vedere se gli utenti riscontrano
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 anche di rivedere la tua infrastruttura di hosting e di confermare disporre di risorse adeguate per gestire il traffico ricevuto dal sito web. Condivisa i provider host sono spesso soggetti a un TTFB elevata e soluzioni dedicate che forniscono tempi di risposta più rapidi possono essere più costosi.
Compressione
Le risposte basate su testo come immagini HTML, JavaScript, CSS e SVG devono compressi per ridurre le dimensioni di trasferimento sulla rete in modo che scaricare più rapidamente. Gli algoritmi di compressione più utilizzati sono gzip e Brotli. Brotli determina un miglioramento del 15-20% circa rispetto a gzip.
La compressione è spesso impostata automaticamente dalla maggior parte dei provider di hosting web, ma devi considerare alcuni aspetti importanti se sei in grado di configurare o modifica personalmente le impostazioni di compressione:
- Se possibile, utilizza Brotli. Come detto in precedenza, Brotli offre una notevole miglioramento rispetto a gzip, e Brotli è supportato in tutti i principali browser supportati. Utilizza Brotli quando possibile, ma se il tuo sito web è utilizzato da un pubblico di utenti su browser legacy, assicurati che gzip sia utilizzato come riserva poiché ogni compressione è migliore di nessuna compressione.
- Le dimensioni dei file sono importanti. Le risorse molto piccole, meno di 1 KiB, non comprimono molto bene o a volte non comprimono affatto. Efficacia di qualsiasi tipo di compressione dei dati dipende dalla presenza di una grande quantità di dati che un algoritmo di compressione per trovare bit più comprimibili di dati. Più grande è un file, migliore sarà la compressione; tuttavia, non distribuiscono risorse molto grandi per il solo fatto che possano essere compresse maggiormente in modo efficace. Risorse di grandi dimensioni, come JavaScript e CSS ad esempio, prendono molto più tempo per l'analisi e la valutazione, dopo che il browser decompressi e potrebbero cambiare più spesso anche se hanno solo modificato marginalmente, poiché ogni modifica determina un hash del file diverso.
- Confronto tra compressione dinamica e statica. Dinamico e statico sono approcci diversi a quando una risorsa dovrebbe essere è compresso. La compressione dinamica comprime una risorsa nel momento in cui viene richiesta e talvolta ogni volta che viene richiesta. D'altra parte, la compressione statica comprime i file in anticipo, senza richiedere alcuna compressione da eseguire al momento della richiesta. La compressione statica rimuove latenza coinvolta nella compressione stessa, che può contribuire ad aumentare la risposta del server volte nel caso della compressione dinamica. Risorse statiche, come Le immagini JavaScript, CSS e SVG devono essere compresse in modo statico, mentre le immagini di risorse, soprattutto se vengono generate in modo dinamico per utenti devono essere compressi in modo dinamico.
Ottenere la compressione correttamente da soli è impegnativo e spesso è meglio lasciarlo una rete CDN (Content Delivery Network), illustrato nella sezione successiva, per gestire questo aspetto per te. Tuttavia, conoscere questi concetti può aiutarti a se il provider host utilizza correttamente la compressione. Quella conoscenza può trovare opportunità per migliorare le impostazioni di compressione in modo che che possono offrire 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 di cache dal server di origine e, a sua volta, le pubblica dal perimetro a server fisicamente più vicini ai tuoi utenti. La vicinanza fisica al tuo gli utenti riducono il tempo di round trip (RTT), mentre ottimizzazioni come HTTP/2 o HTTP/3, memorizzazione nella cache e compressione consentono alla CDN di gestire i contenuti più rapidamente rispetto a quando verrebbe recuperato dal server di origine. L'utilizzo di una CDN può migliorare significativamente il TTFB del sito web, in alcuni casi.
Verifica le tue conoscenze
Quale tipo di reindirizzamento puoi controllare completamente?
L'intestazione Server-Timing può contenere più metriche.
Quale tipo di server ha più probabilità di essere fisicamente il più vicino al tuo sistema utenti?
A seguire: comprendere il percorso critico
Ora che hai acquisito familiarità con alcune delle considerazioni sulle prestazioni necessarie con il codice HTML del tuo sito web, sei in una posizione migliore per poter caricare il più rapidamente possibile, ma questo è solo l'inizio dell'apprendimento del web le prestazioni dei dispositivi. Ora, la teoria alla base del percorso di rendering critico è in questione. Questo modulo descrive concetti chiave come il blocco della visualizzazione risorse di blocco dell'analisi e il ruolo che svolgono nell'ottenere il nel browser il più rapidamente possibile.