Evitare richieste di rete non necessarie con la cache HTTP

Il recupero delle risorse tramite la rete è lento e costoso:

• Le risposte di grandi dimensioni richiedono molti viaggi di andata e ritorno tra il browser e il server.
• La pagina non verrà caricata finché non saranno state scaricate completamente tutte le risorse fondamentali.
• Se una persona accede al tuo sito con un piano di dati mobili limitato, ogni richiesta di rete non necessaria è uno spreco di denaro.

Come si possono evitare le richieste di rete non necessarie? La cache HTTP del browser è la tua prima linea di difesa. Non è necessariamente l'approccio più efficace o flessibile e hai un controllo limitato sulla durata delle risposte memorizzate nella cache, ma è efficace, supportato in tutti i browser e non richiede molto lavoro.

Questa guida illustra le nozioni di base di un'implementazione efficace della memorizzazione nella cache HTTP.

Compatibilità del browser

In realtà non esiste una singola API chiamata Cache HTTP. È il nome generico di una raccolta di API di piattaforme web. Queste API sono supportate in tutti i browser:

Cache-Control

ETag

Last-Modified

Come funziona la cache HTTP

Tutte le richieste HTTP effettuate dal browser vengono innanzitutto inoltrate alla cache del browser per verificare se esiste una risposta memorizzata nella cache valida che può essere utilizzata per soddisfare la richiesta. Se viene trovata una corrispondenza, la risposta viene letta dalla cache, il che elimina sia la latenza della rete sia i costi di dati sostenuti dal trasferimento.

Il comportamento della cache HTTP è controllato da una combinazione di intestazioni di richiesta e intestazioni di risposta. In uno scenario ideale, avrai il controllo sia sul codice dell'applicazione web (che determinerà le intestazioni delle richieste) sia sulla configurazione del server web (che determinerà le intestazioni delle risposte).

Per una panoramica concettuale più approfondita, consulta l'articolo Caching HTTP di MDN.

Intestazioni delle richieste: in genere, mantieni quelle predefinite

Esistono una serie di intestazioni importanti che devono essere incluse nelle richieste in uscita della tua app web, ma il browser si occupa quasi sempre di impostarle per tuo conto quando effettua le richieste. Le intestazioni di richiesta che influiscono sul controllo dell'aggiornamento, come If-None-Match e If-Modified-Since, vengono visualizzate in base alla comprensione da parte del browser dei valori correnti nella cache HTTP.

Questa è una buona notizia: significa che puoi continuare a includere tag come <img src="my-image.png"> nel tuo codice HTML e il browser si occuperà automaticamente della memorizzazione nella cache HTTP, senza alcuno sforzo aggiuntivo.

Intestazioni di risposta: configura il server web

La parte più importante della configurazione della cache HTTP è costituita dalle intestazioni aggiunte dal server web a ogni risposta in uscita. Le seguenti intestazioni vengono tutte prese in considerazione per il comportamento efficace della memorizzazione nella cache:

• Cache-Control. Il server può restituire un'istruzione Cache-Control per specificare in che modo e per quanto tempo il browser e altre cache intermedie devono memorizzare nella cache la singola risposta.
• ETag. Quando il browser trova una risposta memorizzata nella cache scaduta, può inviare un piccolo token (di solito un hash dei contenuti del file) al server per verificare se il file è cambiato. Se il server restituisce lo stesso token, il file è lo stesso e non è necessario scaricarlo di nuovo.
• Last-Modified. Questa intestazione ha lo stesso scopo di ETag, ma utilizza una strategia basata sul tempo per determinare se una risorsa è cambiata, a differenza della strategia basata sui contenuti di ETag.

Alcuni server web supportano l'impostazione di queste intestazioni per impostazione predefinita, mentre altri le ignorano del tutto, a meno che non le configuri esplicitamente. I dettagli specifici su come configurare le intestazioni variano notevolmente a seconda del server web utilizzato e ti consigliamo di consultare la documentazione del server per ottenere i dettagli più precisi.

Per semplificare la ricerca, di seguito sono riportate le istruzioni per la configurazione di alcuni server web di uso comune:

• Express
• Apache
• nginx
• Firebase Hosting
• Netlify

L'omissione dell'intestazione di risposta Cache-Control non disattiva la memorizzazione nella cache HTTP. I browser indovinano il tipo di comportamento di memorizzazione nella cache più adatto per un determinato tipo di contenuti. È probabile che tu voglia un maggiore controllo rispetto a quello offerto, quindi prenditi il tempo di configurare le intestazioni di risposta.

Quali valori dell'intestazione di risposta dovresti utilizzare?

Esistono due scenari importanti che devi considerare quando configuri le intestazioni di risposta del tuo server web.

Memorizzazione nella cache di lunga durata per gli URL con versione

Quando rispondi alle richieste di URL che contengono "impronte" o informazioni sulla versione e i cui contenuti non devono mai cambiare, aggiungi Cache-Control: max-age=31536000 alle risposte.

L'impostazione di questo valore indica al browser che,quando deve caricare lo stesso URL in qualsiasi momento nell'arco del prossimo anno (31.536.000 secondi,il valore massimo supportato), può utilizzare immediatamente il valore nella cache HTTP, senza dover effettuare alcuna richiesta di rete al server web. Ottimo, hai subito ottenuto l'affidabilità e la velocità che derivano dall'evitare la rete.

Strumenti di compilazione come webpack possono automatizzare il processo di assegnazione delle impronte hash agli URL degli asset.

Convalida del server per gli URL senza versione

Purtroppo, non tutti gli URL caricati sono sottoposti a controllo della versione. È possibile che tu non riesca a includere un passaggio di compilazione prima di eseguire il deployment dell'app web, quindi non puoi aggiungere hash agli URL delle risorse. Inoltre, ogni applicazione web ha bisogno di file HTML, che (quasi) mai includeranno informazioni sul controllo delle versioni, poiché nessuno si preoccuperà di utilizzare la tua app web se deve ricordare che l'URL da visitare è https://example.com/index.34def12.html. Cosa puoi fare per questi URL?

Questo è uno scenario in cui devi ammettere la sconfitta. La sola memorizzazione nella cache HTTP non è sufficiente per evitare completamente la rete. Non preoccuparti: a breve scoprirai i service worker, che ti forniranno l'assistenza necessaria per ribaltare la situazione a tuo favore. Tuttavia, puoi seguire alcuni passaggi per assicurarti che le richieste di rete siano il più rapide ed efficienti possibile.

I seguenti valori Cache-Control possono aiutarti a ottimizzare la posizione e il modo in cui vengono memorizzati nella cache gli URL senza versione:

• no-cache. In questo modo, il browser viene informato che deve convalidare nuovamente il server ogni volta prima di utilizzare una versione memorizzata nella cache dell'URL.
• no-store. In questo modo, il browser e altre cache intermedie (come le CDN) non memorizzeranno mai alcuna versione del file.
• private. I browser possono memorizzare nella cache il file, ma le cache intermedie non possono.
• public. La risposta può essere memorizzata da qualsiasi cache.

Consulta l'Appendice: diagramma di flusso Cache-Control per visualizzare la procedura per decidere quali valori Cache-Control utilizzare. Cache-Control può anche accettare un elenco di direttive separate da virgole. Consulta l'appendice: esempi di Cache-Control.

Può essere utile anche impostare ETag o Last-Modified. Come indicato in Intestazioni di risposta, ETag e Last-Modified hanno entrambi lo stesso scopo: determinare se il browser deve scaricare di nuovo un file memorizzato nella cache scaduto. Ti consigliamo di utilizzare ETag perché è più preciso.

L'impostazione ETag o Last-Modified rende la richiesta di convalida molto più efficiente consentendo di attivare le intestazioni di richiesta If-Modified-Since o If-None-Match indicate in Intestazioni di richiesta.

Quando un server web configurato correttamente vede queste intestazioni di richiesta in entrata, può verificare se la versione della risorsa già presente nella cache HTTP del browser corrisponde alla versione più recente sul server web. Se viene trovata una corrispondenza, il server può rispondere con una risposta HTTP 304 Not Modified, che equivale a "Continua a utilizzare ciò che hai già." Quando si invia questo tipo di risposta, i dati da trasferire sono molto pochi, quindi in genere è molto più veloce rispetto a dover inviare una copia della risorsa richiesta.

Riepilogo

La cache HTTP è un modo efficace per migliorare le prestazioni di caricamento perché riduce le richieste di rete non necessarie. È supportato in tutti i browser e non richiede troppi sforzi per la configurazione.

Le seguenti configurazioni Cache-Control sono un buon punto di partenza:

• Cache-Control: no-cache per le risorse che devono essere convalidate di nuovo con il server prima di ogni utilizzo.
• Cache-Control: no-store per le risorse che non devono mai essere memorizzate nella cache.
• Cache-Control: max-age=31536000 per le risorse con versione.

L'intestazione ETag o Last-Modified può aiutarti a convalidare nuovamente le risorse della cache scadute in modo più efficiente.

Scopri di più

Se vuoi andare oltre le nozioni di base sull'utilizzo dell'intestazione Cache-Control, consulta la guida di Jake Archibald Caching best practices and max-age gotchas (Best practice per la memorizzazione nella cache e problemi relativi a max-age).

Consulta Ama la tua cache per indicazioni su come ottimizzare l'utilizzo della cache per i visitatori di ritorno.

Appendice: altri suggerimenti

Se hai più tempo, ecco altri modi per ottimizzare l'utilizzo della cache HTTP:

• Utilizza URL coerenti. Se pubblichi gli stessi contenuti su URL diversi, questi verranno recuperati e archiviati più volte.
• Riduci al minimo il tasso di abbandono. Se parte di una risorsa (ad esempio un file CSS) viene aggiornata di frequente, mentre il resto del file no (ad esempio il codice della libreria), ti consigliamo di suddividere il codice che viene aggiornato di frequente in un file separato e di utilizzare una strategia di memorizzazione nella cache di breve durata per il codice che viene aggiornato di frequente e una strategia di memorizzazione nella cache di lunga durata per il codice che non cambia spesso.
• Consulta la nuova direttiva stale-while-revalidate se è accettabile un certo grado di inattività nelle tue norme relative a Cache-Control.

Appendice: diagramma di flusso Cache-Control

Appendice: esempi di Cache-Control