Che cos’è la cache di un sito web e perché a volte vedi pagine vecchie

La cache di un sito web è una copia già pronta di un contenuto, conservata per evitare di ricostruirlo da zero a ogni visita. Questa copia può trovarsi nel browser del visitatore, sul server, dentro l’applicazione o più vicino all’utente tramite un CDN. Il principio è semplice: se la stessa risposta serve spesso, conviene riutilizzarla invece di rifarla ogni volta.

Che cosa significa davvero una copia in cache

Una copia in cache non è un contenuto diverso. È una risposta già assemblata e conservata per essere riusata. Se una homepage è uguale per la maggior parte dei visitatori, il sito può tenere pronta quella versione e servirla senza rifare tutto il lavoro. La cache non migliora il contenuto in sé; cambia il modo in cui viene consegnato.

Questo è utile perché molte pagine vengono richieste più volte senza cambiare tra una visita e l’altra. Un articolo, una pagina di servizio o una scheda prodotto possono essere viste molte volte con lo stesso risultato. La cache riduce il lavoro ripetuto e permette al sito di rispondere senza riassemblare tutto da capo.

Dove può vivere la cache

Quando si parla di cache, in realtà si parla di più livelli.

• Cache del browser: il browser salva file come immagini, CSS e alcuni script per non riscaricarli subito.
• Page cache: viene salvata l’intera pagina HTML già costruita.
• Cache lato server: il server o l’applicazione conserva risultati pronti per evitare lavori ripetuti.
• Object cache: vengono memorizzati dati più piccoli, come risultati di query o calcoli che si ripetono.
• Cache del CDN: le copie vengono distribuite su nodi più vicini ai visitatori.

Se vuole vedere come questo livello si comporta quando la stessa informazione viene richiesta spesso, può leggere che cosa fa Redis object cache quando una pagina richiede gli stessi dati più volte. L’object cache non sostituisce gli altri livelli, ma è molto utile quando la stessa informazione viene richiesta in continuazione.

Ogni livello ha un ruolo diverso. La cache del browser aiuta lo stesso utente quando torna sul sito. La page cache consente al sito di servire una pagina già pronta a molti visitatori. La object cache riduce il numero di richieste ripetute alla base dati. La cache del CDN avvicina il contenuto all’utente dal punto di vista geografico.

Contenuto statico e contenuto dinamico

Il contenuto statico è quasi uguale per tutti. Il contenuto dinamico cambia in base all’utente, alla sessione, a ciò che ha nel carrello o al fatto che abbia effettuato l’accesso. La cache funziona bene quando il contenuto resta stabile. Richiede più attenzione quando la pagina dipende dallo stato della sessione o da dati personali.

Un articolo di blog si può spesso mettere in cache senza problemi particolari. Un’area account, un carrello o una pagina di checkout sono diversi, perché riflettono uno stato attivo dell’utente. Anche una homepage può mescolare elementi fissi e sezioni che cambiano spesso. Il sito deve distinguere con cura ciò che può essere riutilizzato e ciò che deve rimanere dinamico.

Perché a volte si vede una versione vecchia

Quando cambia un prezzo, un testo o un’immagine, l’aggiornamento non sempre appare subito ovunque. Una copia precedente può essere ancora presente nella cache del browser, nella page cache o nel CDN. Questo non significa necessariamente che l’aggiornamento sia fallito. Spesso vuol dire solo che la copia salvata non è ancora scaduta o non è stata purgata.

Qui entra in gioco il TTL, cioè il tempo per cui una copia resta valida. Quando quel tempo scade, la copia viene considerata obsoleta e deve essere aggiornata. Alcuni sistemi lo fanno automaticamente; altri richiedono una purge o invalidazione, cioè la rimozione della copia vecchia per generare quella nuova. È per questo che, a volte, una pagina sembra mostrare ancora la versione precedente.

Per un proprietario di sito, la chiave è capire quale livello sta rispondendo. Spesso il problema non è il contenuto originale, ma una copia intermedia che non è stata ancora sostituita.

Utenti loggati, carrello e checkout

La cache funziona meglio quando tutti vedono la stessa cosa. Gli utenti loggati sono diversi, perché il loro profilo, le impostazioni o i contenuti legati all’account possono cambiare. Se una pagina personalizzata venisse trattata come se fosse pubblica, potrebbe mostrare informazioni sbagliate alla persona sbagliata. Per questo le aree private hanno quasi sempre regole speciali.

Negli store e-commerce il tema diventa ancora più sensibile. Il carrello, la sessione e il checkout devono restare legati all’utente attivo. Una scheda prodotto può spesso beneficiare della cache; un carrello, molto meno. L’obiettivo non è cacheare tutto, ma cacheare solo ciò che può essere riusato senza rompere l’esperienza.

• Le pagine pubbliche sono le candidate migliori per la cache.
• Carrello, checkout e account devono restare sensibili alla sessione.
• È normale che un sito mescoli parti in cache e parti dinamiche.

Quando aiuta e quando confonde

La cache aiuta quando la stessa risorsa viene richiesta più volte e il contenuto cambia raramente. Può confondere quando ci si aspetta un aggiornamento immediato ma il sito continua a servire una copia precedente. In questi casi non è detto che la cache sia il problema. Più spesso, è una determinata layer che non è ancora stata aggiornata.

Per distinguere meglio la cache dagli altri motivi per cui un sito sembra lento, può leggere perché un sito può sembrare lento anche quando usa la cache. La sensazione di lentezza e la presenza di contenuti vecchi non sempre dipendono dalla stessa causa.

La cache non è un backup né un’ottimizzazione del database

Questi concetti vengono spesso confusi, ma svolgono funzioni diverse. Un backup serve per il ripristino dopo un problema. È una copia di sicurezza, non un livello di velocità. L’ottimizzazione del database migliora il modo in cui i dati vengono conservati e cercati, ma non sostituisce una risposta in cache. Un CDN distribuisce il contenuto da punti più vicini al visitatore e può usare la cache, ma non coincide con la cache del sito.

Tenere separati questi strumenti evita interpretazioni sbagliate. Un backup non accelera una pagina. Un CDN non sistema da solo una struttura dati poco efficiente. La cache non ripara contenuti rotti e non sostituisce una buona architettura del sito. Ogni strumento risolve un problema diverso.

Quando WordPress e i negozi online cambiano le regole

In ambienti WordPress e in siti con aree di acquisto, non tutte le pagine possono essere trattate allo stesso modo. Le pagine pubbliche sono spesso ottime candidate per la cache, mentre il carrello e il checkout richiedono più attenzione per non interferire con la sessione.

Per un contesto più specifico legato ai negozi online, può leggere che cos’è WooCommerce e perché cart e checkout vanno gestiti con cautela. Aiuta a capire perché alcune parti possono essere riusate e altre devono restare sempre aggiornate.

Il caching del sito riduce il lavoro ripetuto, ma resta importante capire il tempo di prima risposta: per questo TTFB e Core Web Vitals sono il completamento naturale.

Quando entrano in gioco contenuti dinamici, aiutano anche un CDN e WordPress, perché il cache di pagina non basta sempre senza un livello applicativo come Redis object cache.