La cache è un sistema che conserva una copia di dati o risorse già recuperati o elaborati, in modo da poterli riutilizzare più rapidamente quando servono di nuovo. L’obiettivo è evitare di ripetere ogni volta un’operazione più lenta: leggere dalla memoria principale, interrogare un database, scaricare un file dalla rete o generare nuovamente una pagina.
È un principio che trovi praticamente ovunque. Il processore usa una memoria dedicata per accedere rapidamente ai dati più frequenti, il browser conserva copie di immagini e file di un sito, una CDN può distribuire contenuti già memorizzati da server vicini agli utenti e WordPress può evitare di ricostruire una pagina identica a ogni visita.
Ma definire la cache semplicemente come “memoria temporanea” lascia fuori la parte più interessante.
Il vero problema che ogni sistema di caching deve risolvere è questo: quando una copia può essere riutilizzata e quando invece deve essere aggiornata?
È da questa domanda che derivano concetti come cache hit, cache miss, TTL, freshness, validazione e invalidazione. Capirli permette anche di capire perché questo meccanismo può rendere un sistema molto più veloce, ma allo stesso tempo può essere la ragione per cui continui a vedere una vecchia versione di una pagina che hai appena modificato.
Cos’è la cache e cosa significa davvero “memoria temporanea”
In informatica, una cache è un livello di memorizzazione progettato per rendere più rapido l’accesso a informazioni che potrebbero servire nuovamente.
Il principio è semplice.
Immagina di richiedere una risorsa a una fonte relativamente lenta. La prima volta il sistema recupera l’originale e, quando previsto, ne conserva una copia. Alla richiesta successiva controlla prima ciò che ha memorizzato: se trova una copia utilizzabile, evita almeno parte del lavoro necessario per tornare alla fonte originale.
Il sistema funziona quindi perché sposta dati frequentemente utilizzati più vicino al punto in cui vengono richiesti, oppure evita di ripetere elaborazioni costose.
Nel Web la specifica di riferimento è HTTP Caching, definita dalla RFC 9111. Lo standard descrive una cache HTTP come un archivio locale di messaggi di risposta e il sistema che ne governa memorizzazione, recupero e cancellazione.
La parola “temporanea”, però, può essere fuorviante. Non significa necessariamente che un dato debba sparire dopo pochi secondi. Una risorsa può restare memorizzata per minuti, giorni o molto più a lungo: ciò che conta è la politica con cui viene conservata e considerata riutilizzabile.
Cache, memoria cache e caching: tre termini collegati ma non identici
Nel linguaggio comune i termini vengono spesso usati come sinonimi, ma indicano cose leggermente diverse.
Cache indica il sistema o lo spazio in cui vengono conservate copie riutilizzabili.
Memoria cache viene utilizzato soprattutto quando si parla di hardware e processori, ma può essere usato più genericamente per indicare lo spazio destinato ai dati memorizzati.
Caching indica invece il processo: decidere cosa memorizzare, per quanto tempo, come recuperarlo e quando aggiornarlo o eliminarlo.
Questa distinzione è utile perché il caching non coincide con il semplice “salvare dei file”. La parte difficile è stabilire quale copia può soddisfare una nuova richiesta senza restituire informazioni sbagliate o obsolete.
Cache e RAM non sono la stessa cosa
Cache e RAM vengono spesso confuse perché entrambe possono contenere dati che devono essere accessibili rapidamente, ma non sono equivalenti.
La RAM è la memoria principale utilizzata dal sistema per mantenere dati e programmi necessari durante l’esecuzione. Una cache è invece un livello progettato specificamente per ridurre il costo di accessi successivi.
In un processore, per esempio, le cache L1, L2 e L3 sono memorie molto rapide che mantengono vicino alla CPU dati e istruzioni che probabilmente verranno utilizzati nuovamente.
Nel Web, invece, questo livello di memorizzazione può essere implementato in memoria, su disco, all’interno del browser, sul server oppure su nodi distribuiti geograficamente.
Quindi una cache può usare la RAM, ma “cache” non significa automaticamente RAM.
Come funziona una cache: hit, miss e origine del dato
Il modo più semplice per capire il caching è osservare cosa accade quando arriva una richiesta.
Il sistema identifica ciò che viene richiesto tramite una chiave: potrebbe essere un indirizzo di memoria, una query, una chiave applicativa oppure un URL.
A quel punto controlla se dispone già di una copia adatta.
Il flusso concettuale è:
richiesta → ricerca nella cache → cache hit o cache miss → eventuale recupero dall’origine → risposta → possibile aggiornamento della copia
L’origine è la fonte autorevole da cui il dato può essere recuperato quando il livello intermedio non può rispondere. Nel caso di un sito può essere il web server, l’applicazione, il database o un altro servizio a monte.
Cache hit: quando la copia è già disponibile
Si verifica un cache hit quando il sistema trova una rappresentazione utilizzabile della risorsa richiesta.
Se quella copia può essere riutilizzata immediatamente, evita di raggiungere la fonte originale.
In un browser potrebbe significare caricare un’immagine dal dispositivo anziché scaricarla di nuovo. In una CDN potrebbe significare servire un file da un nodo edge anziché far arrivare la richiesta fino al server origin. In un’applicazione può significare recuperare un risultato da Redis invece di ripetere una query costosa al database.
Il vantaggio non deriva quindi dalla memorizzazione in sé, ma dal lavoro che non deve essere ripetuto.
Cache miss: quando bisogna tornare alla fonte originale
Un cache miss si verifica quando la risorsa non è presente oppure la copia disponibile non può soddisfare la richiesta.
Il sistema deve allora recuperare o calcolare il dato dalla fonte originale.
Dopo averlo ottenuto può conservarne una copia, affinché richieste successive abbiano maggiori probabilità di produrre un hit.
Un miss non indica necessariamente un problema. È inevitabile, per esempio, quando una risorsa viene richiesta per la prima volta.
Perché una cache piccola può comunque essere molto efficace
Una cache non deve contenere tutti i dati possibili.
In molti sistemi le richieste non sono distribuite uniformemente: alcune risorse vengono utilizzate molto più spesso di altre. Conservare rapidamente proprio quelle può evitare una grande quantità di operazioni costose.
Per questo esistono politiche di eviction, cioè criteri con cui il sistema decide quali elementi rimuovere quando lo spazio disponibile non è sufficiente.
L’obiettivo non è quindi “conservare tutto”, ma mantenere il più possibile i dati che hanno maggiore probabilità di essere riutilizzati.
Il problema più importante: quando una copia in cache è ancora valida
Trovare una risorsa memorizzata non significa automaticamente poterla usare.
Supponi di modificare un’immagine sul server mentre il browser conserva ancora la versione precedente. La copia esiste, ma potrebbe non rappresentare più lo stato corrente della risorsa.
È qui che entra in gioco il concetto di freshness.
Fresh, stale e TTL: la differenza tra presenza e validità
Nel caching HTTP una risposta viene considerata fresh, cioè fresca, quando può essere riutilizzata senza dover prima chiedere al server se è cambiata.
Quando supera il proprio periodo di freshness diventa stale, cioè potenzialmente obsoleta.
Stale non significa necessariamente “sbagliata”. Significa che il sistema non può più presumere automaticamente che quella copia sia ancora quella corretta.
Il TTL, Time To Live, esprime in molti sistemi quanto a lungo un elemento può essere considerato valido o mantenuto prima che sia necessario un nuovo controllo o una sostituzione. Nel caching HTTP il comportamento viene governato principalmente dalle direttive delle risposte, come Cache-Control.
Se una risorsa cambia raramente puoi permetterti una durata maggiore. Se cambia continuamente, una durata troppo lunga aumenta il rischio di mostrare informazioni non aggiornate.
La configurazione corretta è quindi un compromesso fra:
velocità e riutilizzo della copia ↔ freschezza del contenuto
Scadenza, validazione e invalidazione non significano la stessa cosa
Questi tre concetti vengono spesso mescolati.
Scadenza significa che il sistema non può più considerare automaticamente fresca la copia.
Validazione significa chiedere alla fonte originale se la copia conservata corrisponde ancora alla versione corrente. Se non è cambiata, può essere riutilizzata senza scaricare nuovamente l’intera risorsa.
Invalidazione significa rendere una copia non più utilizzabile come se fosse ancora corrente, generalmente perché sappiamo che l’originale è cambiato.
In alcuni sistemi è possibile anche effettuare un purge, cioè eliminare esplicitamente una risorsa memorizzata.
Questa distinzione spiega perché cancellare tutto non dovrebbe essere il normale metodo con cui un sistema mantiene aggiornati i dati. Una buona strategia di caching cerca invece di aggiornare o validare le copie quando serve.
Perché “svuotare tutto” non è il normale funzionamento di una cache
Se per vedere ogni modifica devi cancellare manualmente tutte le copie memorizzate, probabilmente non stai osservando il comportamento ideale del sistema.
Normalmente il meccanismo dovrebbe gestire scadenze, invalidazione, versionamento o validazione delle risorse.
Lo svuotamento manuale resta però un ottimo strumento diagnostico: elimina temporaneamente una variabile e permette di capire se una vecchia copia sta causando il problema.
Vedremo più avanti quando ha senso farlo.
I principali tipi di cache, dal processore al Web
La stessa idea viene applicata a livelli molto diversi.
| Tipo di cache | Dove opera | Cosa evita principalmente |
|---|---|---|
| Cache CPU | processore | accessi più lenti alla memoria |
| Cache applicativa | applicazione | calcoli o recuperi ripetuti |
| Browser cache | dispositivo dell’utente | download ripetuti |
| Cache server | infrastruttura web | generazione ripetuta di pagine o dati |
| Object cache | applicazione/database | query e calcoli ripetitivi |
| CDN cache | rete distribuita | richieste fino all’origin |
| DNS cache | client/resolver DNS | nuove risoluzioni DNS identiche |
Non sono sistemi intercambiabili. Possono funzionare contemporaneamente e, proprio per questo, una stessa risorsa può esistere in più copie collocate a livelli differenti.
Cache CPU e memoria di sistema
La cache della CPU mantiene dati e istruzioni vicino ai core del processore per ridurre il tempo necessario a recuperarli dalla memoria principale.
I processori moderni dispongono generalmente di più livelli con differenti capacità, velocità e vicinanza ai core.
Più ci avviciniamo al processore, la memoria tende a essere più veloce e costosa in termini di spazio disponibile.
È il caso classico che ha reso familiare il termine “memoria cache”, ma non rappresenta l’unico significato della parola.
Cache delle applicazioni
Un software può memorizzare dati già recuperati o risultati di elaborazioni che prevedibilmente serviranno di nuovo.
Un’app può conservare miniature, file temporanei o informazioni scaricate in precedenza. Un’applicazione web può invece memorizzare risultati di query, sessioni, configurazioni o oggetti calcolati frequentemente.
In sistemi più complessi vengono utilizzati strumenti in-memory come Redis o Memcached per evitare di interrogare continuamente database o servizi più costosi.
In questo caso il caching non riguarda necessariamente file: può riguardare oggetti e dati applicativi.
Cache del browser
Quando navighi sul Web, il browser può conservare risposte HTTP e risorse come CSS, JavaScript, immagini e font.
Quando incontra nuovamente la stessa risorsa può controllare se dispone già di una risposta riutilizzabile.
Se sì, può evitare un nuovo download completo.
È il motivo per cui una seconda visita a un sito può comportare un trasferimento di dati inferiore rispetto alla prima, anche se il comportamento effettivo dipende dalle intestazioni HTTP e dalla configurazione del sito.
Se vuoi approfondire la configurazione lato WordPress, trovi una guida specifica sul browser caching in WordPress.
Cache lato server e cache del sito
Sul server possiamo intervenire ancora prima che la risposta raggiunga il browser.
Un CMS come WordPress costruisce normalmente le pagine combinando codice, template, configurazioni e dati provenienti dal database. Se il risultato è identico per molti visitatori, generarlo da zero per ogni richiesta può essere inefficiente.
Una page cache può conservare il risultato già prodotto e servirlo direttamente alle richieste compatibili.
Esistono poi object cache, query cache applicative e altri livelli che agiscono su porzioni differenti dell’elaborazione.
Per WordPress ho dedicato un approfondimento separato al caching in WordPress, perché configurazione, plugin e contenuti dinamici richiedono considerazioni proprie.
Cache CDN e DNS: copie distribuite in punti diversi della rete
Una CDN, Content Delivery Network, può memorizzare copie di risorse su server distribuiti geograficamente.
In questo modo una richiesta può essere soddisfatta da un nodo più vicino all’utente senza dover raggiungere ogni volta il server origin.
È uno dei meccanismi utilizzati da piattaforme come Cloudflare, anche se una CDN moderna offre molte altre funzioni oltre al caching.
La cache DNS appartiene invece a un sistema diverso.
Quando un dominio viene risolto, client, sistema operativo, resolver e altri componenti possono conservare temporaneamente i record DNS secondo il loro TTL. Questo evita di ripetere continuamente la stessa risoluzione.
Se il problema riguarda proprio record DNS vecchi, la procedura corretta non è svuotare indiscriminatamente i dati del browser: può essere necessario eseguire un DNS flush.
Come funziona la cache di un sito web
Un sito moderno raramente utilizza un solo livello di cache.
Potresti avere contemporaneamente:
browser → CDN → reverse proxy/server cache → applicazione → object cache → database
Questo significa che la risposta visualizzata dall’utente potrebbe provenire da un livello diverso dall’origin.
Ed è uno dei motivi per cui diagnosticare un problema di caching può diventare meno banale di quanto sembri.
Cosa può essere memorizzato: HTML, CSS, JavaScript, immagini e risposte
Le risorse statiche sono candidate naturali alla memorizzazione.
Un file CSS con un nome versionato, per esempio, può restare invariato per molto tempo. Lo stesso vale per immagini, font e bundle JavaScript quando l’URL cambia a ogni nuova versione.
Anche l’HTML può essere memorizzato, ma richiede maggiore attenzione perché spesso cambia più frequentemente.
Lo stesso principio vale per le risposte API e persino per alcuni contenuti dinamici: dinamico non significa automaticamente non memorizzabile. Significa piuttosto che devi stabilire condizioni di caching compatibili con la frequenza di aggiornamento e con l’eventuale personalizzazione.
Browser, server e CDN possono avere copie diverse della stessa risorsa
Qui nasce una delle situazioni più frequenti.
Modifichi un file sul server, ma il browser possiede ancora una copia valida secondo la propria policy.
Oppure hai eliminato i dati locali del browser, ma una CDN continua a servire una vecchia versione.
Oppure la CDN è aggiornata ma è la page cache di WordPress a restituire l’HTML precedente.
Dire genericamente “è un problema di cache” non basta quindi a identificare la causa.
La domanda utile è:
quale livello sta rispondendo?
Perché una modifica può essere online ma tu continui a vedere la versione vecchia
Supponiamo che tu abbia modificato style.css mantenendo lo stesso URL.
Se il browser ha ricevuto in precedenza una direttiva che gli permette di considerare quella risorsa fresca per un lungo periodo, può continuare a utilizzare la copia locale senza chiedere immediatamente al server se è cambiata.
Per risorse statiche versionate, una strategia molto comune è il cache busting: quando cambia il contenuto cambia anche l’URL, per esempio attraverso un hash o un numero di versione.
La nuova pagina farà riferimento al nuovo URL e la vecchia copia non verrà più scambiata per la risorsa corrente.
È una strategia diversa dal cancellare continuamente tutto: evita il problema alla radice sfruttando proprio il funzionamento del caching.
HTTP caching: Cache-Control, ETag e risposta 304
Sul Web il comportamento della cache viene governato in gran parte attraverso il protocollo HTTP.
Le specifiche sono articolate, ma tre elementi permettono di comprenderne il funzionamento essenziale:
Cache-Control → per quanto e in quali condizioni riutilizzare una risposta
ETag / Last-Modified → come verificare se è cambiata
304 Not Modified → conferma che la copia esistente può essere riutilizzata
La guida HTTP caching di MDN è un ottimo riferimento tecnico se vuoi approfondire le diverse direttive.
Cache-Control decide quando e come una risposta può essere riutilizzata
Cache-Control permette al server di comunicare istruzioni alle cache.
Fra le direttive che vale la pena conoscere:
max-ageindica per quanti secondi una risposta può essere considerata fresca;publicpermette che la risposta sia conservata anche in cache condivise, quando le altre condizioni lo consentono;privatelimita la memorizzazione alle cache private, come quella del browser dell’utente;no-cachenon significa “non memorizzare”: richiede che la risposta venga validata prima del riutilizzo;no-storeindica invece che la risposta non deve essere memorizzata;must-revalidateimpone la validazione di una risposta stale prima di riutilizzarla nei casi previsti dallo standard.
La differenza fra no-cache e no-store è particolarmente importante perché i nomi possono facilmente portare all’interpretazione sbagliata.
ETag e Last-Modified permettono di verificare se la risorsa è cambiata
Una risposta scaduta non deve essere necessariamente scaricata di nuovo per intero.
Il browser può chiedere al server se la versione che possiede è ancora valida.
Con ETag, il server associa alla rappresentazione della risorsa un identificatore. Alla richiesta successiva il client può inviare quel valore tramite If-None-Match.
Se coincide ancora con la versione corrente, non serve ritrasferire il contenuto.
Un meccanismo simile utilizza Last-Modified e If-Modified-Since, basandosi sulla data di modifica.
La validazione permette quindi di ottenere un risultato importante: mantenere contenuti aggiornati senza rinunciare ai vantaggi del caching.
304 Not Modified: validare senza riscaricare tutto
Se il server riceve una richiesta condizionale e stabilisce che la risorsa non è cambiata, può rispondere con:
304 Not Modified
La risposta non contiene nuovamente l’intero body della risorsa. Comunica essenzialmente al client che può continuare a usare ciò che possiede.
Se invece la risorsa è cambiata, il server può restituire la nuova versione con una normale risposta 200 OK.
Quindi:
fresh → usa direttamente la copia
stale + validazione positiva → 304 e riusa la copia
stale + contenuto cambiato → recupera la nuova versione
Questo modello è molto più accurato dell’idea “quando la cache scade bisogna cancellarla”.
A cosa serve la cache e quali vantaggi offre davvero
Il caching è utile quando il costo necessario per recuperare o ricostruire un’informazione è superiore al costo di conservarne e riutilizzarne una copia.
Nel Web i vantaggi principali sono tre.
Riduzione della latenza e tempi di risposta
Una risorsa già disponibile vicino al client può essere recuperata più rapidamente rispetto alla stessa risorsa richiesta a una fonte più distante o lenta.
Se un’immagine viene letta dalla cache del browser, per esempio, non deve attraversare nuovamente Internet.
Se viene fornita da una CDN, la richiesta può fermarsi a un edge server anziché raggiungere l’origin.
La distanza non è l’unico fattore, ma è facile capire perché evitare lavoro e trasferimenti inutili può ridurre la latenza.
Meno traffico di rete e meno lavoro per il server
Ogni richiesta soddisfatta senza dover trasferire nuovamente il contenuto completo può ridurre la quantità di dati scambiati.
Sul server il beneficio può essere ancora maggiore.
Se una pagina viene servita da una copia già pronta senza eseguire ogni volta PHP e query al database, diminuiscono il lavoro computazionale e la pressione sull’infrastruttura.
Questo diventa particolarmente importante sui siti con molte richieste.
Scalabilità: perché la cache diventa più importante con molte richieste
Supponi che una query richieda 100 millisecondi e venga eseguita una volta: probabilmente non hai un grosso problema.
Se quella stessa elaborazione viene richiesta migliaia di volte, il costo si accumula.
Il caching può trasformare molte operazioni ripetute in accessi a una copia già pronta.
Per questo viene utilizzato non soltanto per rendere più veloce la singola richiesta, ma anche per ridurre il lavoro che l’infrastruttura deve sostenere quando cresce il traffico.
Quando la cache crea problemi
Il meccanismo è efficace proprio perché riutilizza informazioni precedenti. Ma lo stesso principio genera il suo rischio fondamentale: riutilizzare una copia quando non dovremmo.
Contenuti vecchi o modifiche che non compaiono
È il problema più evidente.
Hai aggiornato una pagina, un CSS, un’immagine o una configurazione ma continui a vedere la versione precedente.
Prima di cancellare tutto, conviene capire quale layer potrebbe essere coinvolto:
browser, plugin WordPress, server, CDN, object cache o DNS.
Identificare il livello evita di eliminare dati che non hanno nessuna relazione con il problema.
Cache configurata male su contenuti dinamici o personalizzati
Non tutto deve essere condiviso fra tutti gli utenti.
Un’area personale, un carrello ecommerce o una pagina che cambia in base alla sessione possono contenere informazioni specifiche per una persona.
Servire indiscriminatamente la stessa copia a utenti differenti può produrre errori funzionali e, negli scenari peggiori, esposizione di informazioni che avrebbero dovuto rimanere private.
Per questo HTTP distingue anche cache private e condivise e permette di controllare la memorizzazione tramite direttive specifiche.
Più il contenuto dipende dall’identità o dallo stato dell’utente, maggiore deve essere l’attenzione al caching.
Il problema della cache invalidation
La cache invalidation è considerata uno dei problemi classici dell’informatica perché sembra semplice finché non bisogna mantenere sincronizzate molte copie.
Quando cambia l’origine, come facciamo a sapere quali copie dipendono da quel dato?
Se invalidiamo troppo poco rischiamo contenuti stale.
Se invalidiamo troppo spesso perdiamo buona parte del beneficio del caching.
Nei sistemi distribuiti il problema diventa ancora più evidente perché possono esistere copie su server, nodi edge e client differenti.
La strategia corretta dipende quindi dal tipo di contenuto, dalla frequenza con cui cambia e da quanto è grave servire temporaneamente una versione precedente.
Svuotare la cache: quando serve e quando è inutile
Cancellare la cache non rende automaticamente un computer o un sito “più veloce”.
In realtà, subito dopo la cancellazione alcune operazioni possono essere più lente, perché dati e risorse devono essere recuperati nuovamente e il sistema deve ricostruire le copie utili.
Cosa succede realmente quando cancelli la cache
Eliminando una cache rimuovi le copie che il sistema avrebbe potuto riutilizzare.
Alla richiesta successiva dovrà quindi tornare alla fonte originale oppure ricreare le informazioni necessarie.
La nuova risposta potrà poi essere nuovamente memorizzata.
Questo è utile se la copia precedente era corrotta o obsoleta, ma non significa che debba essere cancellata periodicamente per funzionare correttamente.
Quando cancellarla è un buon test diagnostico
Ha senso provare a svuotare una cache quando:
- una modifica nota non compare;
- un sito continua a mostrare risorse precedenti;
- un’app sta utilizzando dati locali apparentemente incoerenti;
- stai cercando di capire se il problema dipende da una copia memorizzata.
L’operazione dovrebbe però essere mirata al livello corretto.
Se hai bisogno delle procedure per Chrome, Firefox, Safari, Windows, macOS, Android o altri dispositivi, trovi tutti i passaggi nella guida dedicata a come svuotare la cache.
Perché non è necessario pulirla periodicamente “per principio”
Un sistema correttamente gestito dispone già di meccanismi per scadenza, sostituzione e invalidazione.
Eliminare continuamente i dati memorizzati impedisce di beneficiare pienamente delle copie già disponibili.
Esistono naturalmente eccezioni: problemi software, dati danneggiati, limiti di spazio o procedure specifiche possono richiedere una pulizia.
Ma “svuota la cache regolarmente per velocizzare il dispositivo” non è una regola generale affidabile.
Cache e cookie vengono spesso cancellati dalla stessa schermata del browser, ma svolgono funzioni diverse.
La cache conserva principalmente copie riutilizzabili di risorse o risposte per ridurre lavoro e trasferimenti successivi.
I cookie sono piccoli dati associati a un sito che il browser può inviare nelle richieste successive. Vengono utilizzati, a seconda del caso, per sessioni, preferenze, autenticazione e altre informazioni di stato.
La conseguenza pratica è importante.
La cache riusa risorse, i cookie conservano informazioni di stato
Se elimini la cache, il browser dovrà normalmente recuperare nuovamente alcune risorse.
Se elimini determinati cookie, invece, potresti perdere una sessione autenticata, alcune preferenze o altri stati mantenuti dal sito.
Sono quindi due strumenti differenti che vengono raggruppati nelle impostazioni del browser soprattutto perché entrambi fanno parte dei dati conservati localmente.
Perché cancellare cache e cookie può produrre effetti molto diversi
Se un’immagine continua a essere vecchia, eliminare il cookie difficilmente risolverà il problema.
Se non riesci più a mantenere una sessione corretta, cancellare una risposta CSS memorizzata potrebbe essere altrettanto irrilevante.
Quando fai troubleshooting, distinguere i due meccanismi permette di agire sulla causa anziché usare la generica procedura “cancella tutti i dati del browser”.
Cache, performance e SEO: cosa possiamo affermare davvero
Il caching può contribuire in modo importante alle performance di un sito, ma da qui nasce spesso una semplificazione SEO:
“attivare la cache migliora automaticamente il ranking”.
Non funziona così.
La cache può aiutare le performance, ma non è un ranking factor autonomo
Una buona strategia di caching può ridurre trasferimenti, lavoro del server e latenza in diversi scenari.
Questo può contribuire a rendere il sito più rapido e l’esperienza migliore.
Google documenta che i Core Web Vitals vengono utilizzati dai suoi sistemi di ranking, ma chiarisce anche che ottenere valori perfetti non garantisce automaticamente le prime posizioni e che la page experience non può essere ridotta a un singolo segnale.
La cache va quindi trattata per ciò che è: uno degli strumenti tecnici che possono contribuire alle performance, non una leva SEO isolata che produce ranking.
Se vuoi lavorare sul problema nel suo insieme, la ottimizzazione di un sito web deve considerare anche server, codice, immagini, rendering, infrastruttura ed esperienza reale degli utenti.
Core Web Vitals, page experience e il limite delle semplificazioni
Una configurazione efficace può influire soprattutto sulle visite ripetute e, in determinate architetture, sui tempi con cui server e CDN rispondono.
Ma le performance percepite dipendono da molte altre variabili.
Una pagina può avere un caching eccellente ed essere comunque lenta a causa di JavaScript pesante, immagini sovradimensionate, risorse bloccanti, server poco performante o rendering inefficiente.
Per questo ha poco senso considerare “installare un plugin cache” come sinonimo di “ottimizzare la velocità”.
Il caching è un componente della strategia, non l’intera strategia.
Anche Googlebot usa il caching HTTP durante il crawling
C’è un aspetto SEO tecnico meno conosciuto ma molto più preciso.
Google documenta che la sua infrastruttura di crawling supporta il caching HTTP attraverso validatori come ETag/If-None-Match e Last-Modified/If-Modified-Since.
Quando Googlebot dispone di una rappresentazione precedente e il server conferma che non è cambiata, può ricevere una risposta 304 Not Modified anziché trasferire nuovamente l’intero contenuto.
Google spiega anche che questo può ridurre il lavoro del server e, soprattutto sui siti grandi con contenuti che cambiano raramente, contribuire a una scansione più efficiente.
La documentazione ufficiale è disponibile nella sezione dedicata alla memorizzazione nella cache HTTP dei crawler Google.
Questo è un effetto reale e documentato. È molto diverso dall’affermare genericamente che “la cache fa salire il sito su Google”.
La vecchia Google Cache non va confusa con la cache del Web
Per anni Google ha permesso di richiamare attraverso la Ricerca una copia memorizzata di alcune pagine e disponeva dell’operatore cache:.
Questo ha contribuito a creare un po’ di confusione tra Google Cache e il normale caching HTTP.
Sono concetti differenti.
Perché l’operatore cache: di Google non funziona più
Google ha rimosso dalla propria documentazione l’operatore cache: il 24 settembre 2024, specificando che non è più supportato nella Ricerca Google.
La modifica è riportata negli aggiornamenti ufficiali della documentazione di Google Search.
Di conseguenza, una guida che suggerisce oggi di utilizzare cache:example.com per vedere la copia Google di una pagina sta descrivendo una funzione non più disponibile.
Questo non significa che i sistemi Google non utilizzino meccanismi di caching internamente. Significa semplicemente che la vecchia funzione visibile all’utente e il caching tecnico utilizzato sul Web sono due cose diverse.
Indicizzazione, crawling e HTTP cache sono concetti differenti
Il crawling è il processo con cui un crawler recupera risorse.
L’indicizzazione riguarda invece l’elaborazione e l’eventuale memorizzazione delle informazioni necessarie ai sistemi di ricerca.
Il caching HTTP permette di evitare trasferimenti inutili quando una rappresentazione già posseduta può essere riutilizzata o validata.
Una pagina presente nell’indice di Google non deve quindi essere descritta come “presente nella cache di Google” nel vecchio significato dell’operatore cache:.
La distinzione è importante perché evita di applicare un concetto storico a meccanismi tecnici che continuano invece a esistere e ad avere funzioni precise.
Conclusione
La cache funziona perché evita di ripetere lavoro che è già stato fatto. Conserva una copia più conveniente da recuperare e prova a riutilizzarla quando arriva una richiesta compatibile.
Ma il punto fondamentale non è semplicemente memorizzare.
È sapere quando riutilizzare.
Se la copia è fresca, può essere utilizzata direttamente. Se è diventata stale, può essere validata. Se l’originale è cambiato, la copia deve essere aggiornata o invalidata. Se non esiste alcuna copia adatta, il sistema torna all’origine e genera un cache miss.
Una volta compreso questo meccanismo, diventano più chiari anche i problemi pratici: perché una modifica non compare, perché una CDN può mostrare una versione diversa dal server, perché no-cache non significa “non salvare”, perché cancellare periodicamente tutto non è una strategia di ottimizzazione e perché browser cache, DNS cache e cache WordPress richiedono interventi diversi.
Se devi risolvere un problema, quindi, prima di premere “svuota cache” prova a fare una domanda più utile:
quale copia sto vedendo, dove è memorizzata e quale meccanismo dovrebbe aggiornarla?
È quasi sempre da lì che parte una diagnosi migliore.