Cache HTTP e TTL: funzionamento, strategie e impatto sul SEO

La cache HTTP e il TTL (Time To Live) sono due concetti fondamentali delle prestazioni web. La cache consente di memorizzare temporaneamente le risorse (immagini, CSS, JavaScript) vicino all'utente per evitare di doverle scaricare di nuovo ad ogni visita. Il TTL definisce per quanto tempo una risorsa può restare in quella cache prima di essere considerata obsoleta. Configurati correttamente, questi meccanismi riducono notevolmente i tempi di caricamento, alleggeriscono il server di origine e migliorano i Core Web Vitals, con un impatto diretto sul SEO.

Che cos'è la cache HTTP?

La cache HTTP è un meccanismo che consente a diversi componenti della catena di distribuzione di una pagina web di conservare una copia locale delle risorse scaricate. Quando un browser carica una pagina per la prima volta, scarica ogni risorsa dal server. Se queste risorse sono accompagnate da intestazioni HTTP che indicano che possono essere memorizzate nella cache, il browser (e/o la CDN) ne conserva una copia. Nelle visite successive, la risorsa viene servita da quella cache locale invece di essere riscaricata dal server, il che è significativamente più rapido.

Esistono diversi livelli di cache nella catena di distribuzione di una risorsa web. La cache del browser memorizza le risorse direttamente sul dispositivo dell'utente, sul disco rigido o in memoria. La cache CDN (detta anche edge cache) memorizza le risorse sui server della rete di distribuzione geograficamente vicini agli utenti. La cache lato server (reverse proxy cache, come Varnish o Nginx) memorizza le risorse a livello di hosting, prima ancora che raggiungano la rete.

Le intestazioni Cache-Control: come definire il comportamento della cache

L'intestazione HTTP Cache-Control è il principale meccanismo con cui un server comunica le proprie istruzioni di memorizzazione nella cache. Viene inviata con ogni risposta HTTP e può contenere diverse direttive combinate. Ecco le più importanti:

• max-age=N: la risorsa può essere memorizzata nella cache per N secondi. Esempio: max-age=31536000 = 1 anno. La direttiva più usata per le risorse statiche.
• s-maxage=N: come max-age, ma si applica solo alle cache condivise (CDN, reverse proxy), non alla cache del browser. Consente politiche diverse per CDN e browser.
• no-cache: la risorsa può essere memorizzata nella cache, ma la cache deve sempre verificare con il server se è ancora valida prima di servirla (tramite ETag o Last-Modified).
• no-store: la risorsa non deve mai essere memorizzata nella cache, da nessuna parte. Da usare solo per contenuti molto sensibili (dati personali, transazioni).
• public: la risorsa può essere memorizzata nella cache da qualsiasi cache, incluse le cache CDN condivise.
• private: la risorsa può essere memorizzata nella cache solo dal browser dell'utente, non dalle cache intermedie.
• immutable: indica che la risorsa non cambierà mai durante la sua durata (max-age). Il browser non invierà una richiesta di validazione neanche alla scadenza.

Per le immagini statiche di un negozio e-commerce, la direttiva ottimale è generalmente: Cache-Control: public, max-age=31536000, immutable. Questa combinazione indica che l'immagine può essere memorizzata nella cache pubblicamente, per un anno, e che non cambierà. Se l'immagine cambia (nuova foto del prodotto), l'URL deve cambiare per aggirare la cache: una tecnica denominata "cache busting" tramite versionamento dell'URL.

TTL (Time To Live): per quanto tempo conservare una risorsa nella cache?

Il TTL (Time To Live) è la durata per cui una risorsa memorizzata nella cache è considerata fresca (fresh) e può essere servita direttamente senza consultare il server di origine. Viene espresso in secondi nell'intestazione max-age. Trascorso questo periodo, la risorsa è considerata obsoleta (stale): può ancora essere servita in alcuni casi, ma la cache dovrebbe idealmente rivalidarla.

La scelta del TTL è un equilibrio tra due obiettivi contrapposti: massimizzare l'uso della cache (TTL lungo = meno richieste al server) e garantire che gli utenti ricevano contenuti aggiornati (TTL breve = le modifiche si propagano rapidamente). Per le risorse che cambiano raramente, come le immagini dei prodotti, un TTL lungo (1 anno) è ottimale. Per le risorse che cambiano frequentemente, come i prezzi o le disponibilità, è necessario un TTL breve o nullo.

• 1 anno (31.536.000 secondi): immagini di prodotto, CSS/JS versionati, font web — risorse stabili con versionamento URL
• 1 mese (2.592.000 secondi): immagini di brand o di categoria aggiornate occasionalmente
• Da 1 ora a 1 giorno: contenuti semidinamici, pagine di categoria, liste di prodotti
• 0 o no-store: pagine carrello, pagine di pagamento, dati utente autenticato — non memorizzare mai nella cache

Invalidazione della cache: come gestire le modifiche ai contenuti

La memorizzazione nella cache a lungo termine solleva una domanda ovvia: cosa succede quando il contenuto cambia? Se un'immagine è memorizzata nella cache per 1 anno ma viene modificata dopo 2 mesi, i visitatori continueranno a vedere la vecchia versione per 10 mesi. È qui che entrano in gioco le strategie di invalidazione della cache.

La strategia più affidabile è il versionamento dell'URL (URL versioning o cache busting). Il principio: l'URL della risorsa include un identificatore univoco che cambia ogni volta che la risorsa cambia. Ad esempio, /images/prodotto-scarpa-v2.webp invece di /images/prodotto-scarpa.webp. Oppure tramite un parametro: /images/prodotto.jpg?v=1705234567. Quando l'immagine cambia, cambia l'URL, e la cache tratta questo nuovo URL come una risorsa completamente nuova, senza problemi di contenuto obsoleto.

Un'altra strategia è l'API di purge CDN: le CDN moderne espongono un'API che consente di invalidare immediatamente URL specifici o gruppi di URL nella loro cache. Quando un commerciante modifica un'immagine nel pannello di amministrazione, una chiamata API alla CDN invalida la cache per quell'immagine. Le visite successive recuperano la nuova versione direttamente dal server di origine, che viene poi rimessa in cache.

Cache CDN vs cache del browser: complementarità e differenze

La cache CDN e la cache del browser sono complementari e servono scopi diversi. La cache CDN beneficia tutti i visitatori, nuovi e abituali: un'immagine memorizzata nella cache sul nodo CDN di Milano viene servita rapidamente a qualsiasi visitatore in Italia, che abbia o meno già visitato il tuo negozio. La cache del browser beneficia solo i visitatori abituali, sul loro dispositivo: se un utente ha già scaricato l'immagine durante una visita precedente, il suo browser la serve dal disco locale senza alcuna richiesta di rete.

In pratica, i due livelli di cache si completano: la cache CDN riduce la latenza al primo caricamento di una pagina (nuovo visitatore o cache del browser scaduta), mentre la cache del browser elimina completamente la rete per le visite ripetute sullo stesso dispositivo. Una risorsa con max-age=31536000 richiederà solo una richiesta di rete una volta all'anno per dispositivo: un guadagno di prestazioni molto significativo per i visitatori fedeli.

ETag e Last-Modified: la validazione condizionale della cache

Anche con un TTL scaduto, il browser non è costretto a riscaricare una risorsa da zero. Può inviare una richiesta condizionale per verificare se la risorsa è cambiata: se non lo è, il server risponde con il codice HTTP 304 (Not Modified) senza corpo della risposta, risparmiando larghezza di banda e confermando la freschezza della risorsa in cache.

L'ETag (Entity Tag) è un identificatore univoco generato dal server per una versione specifica di una risorsa, tipicamente un hash del contenuto del file. Quando il browser invia una richiesta condizionale, include l'ETag della sua versione in cache nell'intestazione If-None-Match. Se il server ha lo stesso ETag (la risorsa non è cambiata), risponde con 304; altrimenti invia la nuova versione con un nuovo ETag.

L'intestazione Last-Modified funziona in modo simile: il server indica la data dell'ultima modifica della risorsa, e il browser la invia in If-Modified-Since nelle richieste condizionali. Questi meccanismi di validazione permettono di mantenere la cache aggiornata senza sprecare larghezza di banda quando il contenuto non è cambiato.

Come Lexiik gestisce la cache e l'invalidazione automaticamente

Lexiik implementa una strategia di cache ottimale per le immagini dei negozi PrestaShop, risolvendo automaticamente il problema di invalidazione che normalmente rende il caching a lungo termine rischioso. Ogni immagine caricata su Cloudflare R2 riceve le intestazioni Cache-Control: public, max-age=31536000, immutable, ossia un anno di cache su tutti gli edge node di Cloudflare e nei browser dei visitatori.

Il problema dell'invalidazione viene gestito automaticamente da Lexiik tramite due meccanismi. Innanzitutto, il versionamento dell'URL: le immagini servite da Lexiik CDN utilizzano identificatori nei loro URL che cambiano automaticamente quando l'immagine viene modificata nel pannello di amministrazione di PrestaShop. In secondo luogo, le chiamate automatiche all'API di purge di Cloudflare: quando un'immagine cambia, Lexiik invia una richiesta di purge a Cloudflare per invalidare immediatamente la cache CDN per quell'immagine specifica, senza influire sulle altre. I visitatori ricevono la nuova immagine alla loro prossima visita, senza mai vedere una versione obsoleta.

Perché una cache a lungo termine migliora il SEO

Un TTL di un anno sulle immagini di prodotto migliora il SEO attraverso diversi meccanismi diretti e indiretti. Direttamente, le immagini caricate dalla cache (CDN o browser) vengono visualizzate in decine o centinaia di millisecondi, rispetto a diversi secondi per un download di rete completo. Questo migliora l'LCP, la metrica Core Web Vital più correlata alle immagini, e può portare una pagina da un punteggio «Scarso» a «Buono» secondo le soglie di Google.

Indirettamente, una cache efficace riduce il numero di richieste HTTP inviate al tuo server di origine. Meno carico sul server = migliore TTFB (Time To First Byte) per i contenuti HTML dinamici generati dal tuo PrestaShop. Google raccomanda un TTFB inferiore a 200 ms; un server sovraccarico di richieste di immagini può avere un TTFB degradato che incide su tutte le metriche di prestazione.

Infine, per i visitatori abituali, che spesso sono i più propensi a convertire, una cache del browser ben configurata crea un'esperienza di navigazione quasi istantanea. Le pagine prodotto sembrano caricarsi immediatamente, con le immagini già in memoria. Questo fluidifica il processo d'acquisto e riduce i tassi di abbandono, con un impatto positivo sulle metriche comportamentali che Google può considerare.

• LCP migliorato: immagini caricate dalla cache locale o CDN in pochi millisecondi
• TTFB migliorato: meno richieste al server di origine = minor carico del server = HTML consegnato più velocemente
• Punteggio PageSpeed migliore: Google Lighthouse penalizza l'assenza di una politica di cache a lungo termine
• Risparmio di larghezza di banda: meno dati trasferiti = costi inferiori e prestazioni migliori su mobile
• Esperienza migliorata per i visitatori abituali: navigazione quasi istantanea per i clienti fedeli