Intestazioni HTTP per migliorare la velocità di un sito web

L’intestazione HTTP, quel pacchetto di dati tanto importante quanto sconosciuto.

Quando un client come un browser richiede una pagina web ad un web server, prima di ricevere il file HTML il client riceve l’intestazione HTTP del web server.

Questa ad esempio è l’HTTP header che invia questo web server quando un client richiede la homepage:

HTTP/1.1 200 OK
Date: Tue, 10 Nov 2020 14:05:23 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Set-Cookie: __cfduid=d3f3f9a4c4660f3b02e3704d5b38ae9971605017123; expires=Thu, 10-Dec-20 14:05:23 GMT; path=/; domain=.evemilano.com; HttpOnly; SameSite=Lax
Vary: Accept-Encoding
Link: <https://www.evemilano.com/wp-json/>; rel="https://api.w.org/"
X-XSS-Protection: 1; mode=block
X-FastCGI-Cache: HIT
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=15552000; preload
Content-Security-Policy: frame-ancestors 'self'; form-action 'self';
Content-Security-Policy: default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval';
Link: <https://fonts.googleapis.com>; rel=preconnect; crossorigin; probability=1.0;
Link: <https://stats.g.doubleclick.net>; rel=preconnect; crossorigin; probability=1.0;
Link: <https://www.google-analytics.com>; rel=preconnect; crossorigin; probability=1.0;
Link: <https://www.google.com>; rel=preconnect; crossorigin; probability=1.0;
Link: <https://www.google.it>; rel=preconnect; crossorigin; probability=1.0;
Link: <https://fonts.gstatic.com>; rel=preconnect; crossorigin; probability=1.0;
Link: <https://ajax.googleapis.com>; rel=preconnect; crossorigin; probability=1.0;
Link: <https://www.googletagmanager.com>; rel=preconnect; crossorigin; probability=1.0;
Link: </wp-content/plugins/eve_social_buttons/images/socicon.woff>; as=font; crossorigin=anonymous; rel=preload;
Link: </wp-content/uploads/2017/10/evemilano-160x90-azzurro.png>; as=image; rel=preload;
Link: <https://fonts.gstatic.com/s/lato/v17/S6uyw4BMUTPHjx4wXiWtFCc.woff2>; as=font; crossorigin=anonymous; rel=preload;
CF-Cache-Status: DYNAMIC
cf-request-id: 065412d2a900001752719be000000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=NFsa8FKr8WxwGdFSDPca1gzV9L7%2B0NJ2DcUjxPXdTuQCDXfXfbElaSQeL3nSWzpagriHNbtI0zB97f28SMZnwy7l8vtLJbpqsy2WfKfYoSv4fGeoEeSraaZTPulFyg%3D%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 5f0053fddd271752-FRA

Il rendering di una pagina web

Una pagina web contiene diverse dipendenze, come immagini, file CSS e JS, ad esempio. Il browser dopo aver ricevuto la pagina HTML la interpreta (la legge) e la disegna nel frattempo. Quando nel codice HTML viene richiamata una dipendenza, il rendering della pagina si ferma per scaricare la dipendenza ed eventualmente interpretarla se è un CSS o JS. Per quello le dipendenze vengono spesso definite “risorse di blocco“.

Il browser viene a conoscenza delle dipendenze quando le legge nell’HTML, ed i vari blocchi chiaramente influiscono sui tempi totali del rendering della pagina.

Ma se ti dicessi che il web server può suggerire al browser quali risorse servono al rendering della pagina, prima ancora di inviare il file HTML?

In questo blog ho descritto diverse tecniche per anticipare il caricamento delle risorse nel browser:

• Il Preload richiede di scaricare dipendenze, come JS, CSS e font. Il preload è più adatto per le risorse normalmente scoperte in ritardo dal browser, ad esempio nelle critical chain requests. Precaricando una certa risorsa, stai dicendo al browser che vorresti recuperarla prima di quanto altrimenti il browser la scoprirebbe perché sei certo che sia importante per la pagina corrente.
• Il Preconnect e dns-prefetch richiedono di iniziare a stabilire una connessione con il server remoto. È possibile accelerare il tempo di caricamento di 100–500 ms stabilendo connessioni anticipate a importanti origini di terze parti. Questi numeri possono sembrare piccoli, ma fanno la differenza nel modo in cui gli utenti percepiscono le prestazioni della pagina web.
• Il Prefetch indica al browser una risorsa da scaricare non appena sarà finito il caricamento della pagina attiva. Quando il browser incontra il tag inizierà a richiedere la o le risorse come ad esempio un’immagine o una pagina HTML. Il Prefetch permette di scaricare singole risorse come immagini, pagine HTML, fogli di stile, etc. L’impatto del Prefetch sulla velocità di caricamento della pagina dipende quindi da quale risorsa si pre-carica.
• Il Prerender è l’unica opzione che non può essere trasmessa via intestazione HTTP. Il prerender chiede al browser di iniziare a renderizzare una nuova pagina. La funzione di prerendering è la più potente delle tecnologie presentate qui, ma comporta anche i maggiori rischi. In sostanza, garantisce che un URL con tutte le risorse statiche necessarie sia completamente caricato e impostato in background.
• HTTP/2 Server Push è una funzionalità che consente a un server di inviare preventivamente le risorse al client (senza una richiesta corrispondente).

Questi suggerimenti possono essere dati al browser sia inserendoli come meta tag nelle pagine HTML, ma il vero vantaggio è inserirle nelle intestazioni HTTP, dato che viene letta dal client prima rispetto alla pagina web.

Ognuna di queste pratiche può influire in modo più o meno importante sui tempi di caricamento delle pagine e quindi sull’usabilità del sito web. Non bisogna abusare di queste tecniche perché potrebbero avere l’effetto opposto.

I suggerimenti al browser vanno dati in modo oculato, suggerisci solo le risorse critiche al rendering della pagina.

Per fare un esempio, avrebbe senso richiedere il preload del file CSS ed il preconnect ai server di Google Tag Manager (se usi GTM).

Come sapere quali risorse suggerire al browser?

Le risorse più importanti da precaricare sono solitamente quelle coinvolte in catene di richieste critiche, definite “critical chain requests“.

Le catene di richieste critiche sono serie di richieste di rete dipendenti importanti per il rendering della pagina. Maggiore è la lunghezza delle catene e maggiori sono le dimensioni del download, più significativo è l’impatto sulle prestazioni di caricamento della pagina.

Lighthouse, uno strumento dei Chrome DevTools, segnala le richieste critiche caricate con un’alta priorità:

Facciamo un esempio di routine classica:

1. il browser richiede la pagina HTML
2. il browser legge la pagina HTML ed inizia il rendering
3. il browser trova link ad una dipendenza CSS
4. il browser scarica la dipendenza e la interpreta
5. nel CSS il browser trova un richiamo ad un font ospitato su CDN
6. il browser si connette e scarica il font
7. ora il browser può completare il rendering della pagina

Il font fa parte di una critical request chain, dato che dipende dalla lettura del CSS in cui è richiamato. Suggerire al browser nell’intestazione HTTP che, per renderizzare la pagina, gli servirà un CSS ed un font, migliorerebbe drasticamente i tempi di caricamento. Il browser infatti inizierà a procurarsi le dipendenze prima ancora di leggere il file HTML.

Come ridurre l’effetto delle catene di richieste critiche sulle prestazioni

Utilizza i risultati dell’audit delle catene di richieste critiche per indirizzare prima le risorse che hanno l’effetto maggiore sul caricamento della pagina:

• Riduci al minimo il numero di risorse critiche: eliminarle, posticiparne il download, contrassegnarle come asincrone sono possibili soluzioni.
• Ottimizza il numero di byte critici per ridurre il tempo di download (numero di round trip).
• Ottimizza l’ordine in cui vengono caricate le risorse critiche rimanenti: scarica tutte le risorse critiche il prima possibile per ridurre la lunghezza del percorso critico.