La cache è una copia temporanea di una risorsa, tenuta più vicina a chi la richiede per non doverla generare o scaricare daccapo a ogni visita.
In un sito web non ce n'è una sola. Ne convivono almeno tre che contano: quella dentro il browser del visitatore, quella sul server che ospita il sito, quella sui nodi della CDN. Quando qualcuno scrive «ho cambiato il testo ma online vedo ancora quello vecchio», il lavoro è capire in quale dei tre punti è rimasta ferma la copia. Si svuotano in modi diversi e, se li tocchi nell'ordine sbagliato, non succede niente.
I livelli di cache che trovi su un sito
Chi lavora su un sito WordPress ne incontra in genere quattro o cinque, impilati uno sull'altro. Ognuno ha un padrone diverso, e questo spiega perché il pulsante «svuota cache» del plugin a volte non basta.
| Livello | Dove sta | Cosa conserva | Chi lo svuota |
|---|---|---|---|
| Cache del browser | Sul dispositivo del visitatore | CSS, JavaScript, immagini, font | Il visitatore, oppure gli header che invia il sito |
| Cache di pagina | Sul server del sito | L'HTML già assemblato | Il plugin di cache o il pannello dell'hosting |
| Cache degli oggetti | Sul server (Redis, Memcached) | Risultati delle query al database | Il plugin o il servizio che la gestisce |
| Opcode cache | In memoria, dentro PHP (OPcache) | Il codice PHP già compilato | Il riavvio di PHP-FPM |
| Cache della CDN | Sui nodi perimetrali (Cloudflare, Fastly, Varnish) | Risposte HTTP complete | Il purge dal pannello della CDN |
| bfcache | Nella RAM del browser | L'intera pagina, JavaScript compreso | Il browser, da solo |
Dei sei, solo due li governi davvero dal sito: la cache di pagina e quella degli oggetti. Sugli altri quattro il sito può soltanto mandare istruzioni, e sperare che vengano seguite.
Chi decide quanto dura una copia
Le regole non le scrive Google, le scrive lo standard HTTP. Il documento di riferimento è la RFC 9111 «HTTP Caching», pubblicata dall'IETF nel 2022, che ha sostituito la precedente RFC 7234 ed è diventata standard con la sigla STD 98. Definisce tre header: Cache-Control, Expires e Age. Il primo è quello che si usa, gli altri due sono eredità storiche.
Se il server non dice niente, la cache non si arrende: tira a indovinare. La specifica chiama questo comportamento freschezza euristica e suggerisce di stimare la durata come una frazione del tempo trascorso dall'ultima modifica del file, «tipicamente il 10%». Un file modificato dieci giorni fa resta quindi valido circa un giorno, senza che nessuno l'abbia deciso. È il motivo per cui un sito senza header di cache si comporta in modo diverso da browser a browser.
| Direttiva | Cosa ordina | Quando serve |
|---|---|---|
max-age=31536000 | Conserva per un anno senza richiedere niente | File con un hash nel nome, che cambiano nome a ogni deploy |
s-maxage | Vale solo per le cache condivise (CDN, proxy) | HTML che vuoi tenere sulla CDN ma non nel browser |
no-cache | Conserva la copia, ma rivalidala prima di usarla | Pagine che cambiano spesso e devono restare aggiornate |
no-store | Non conservare niente, da nessuna parte | Carrello, checkout, area riservata |
private | Può conservarla il browser, non la CDN | Pagine personalizzate per l'utente loggato |
must-revalidate | Scaduta la copia, vietato servirla lo stesso | Prezzi, disponibilità, dati che non tollerano ritardi |
Accanto alla durata c'è la verifica. Con ETag il server allega a ogni risposta un'impronta del contenuto; il browser la rimanda indietro in If-None-Match alla richiesta successiva e, se l'impronta combacia, riceve un 304 Not Modified senza corpo. Stesso meccanismo con Last-Modified e If-Modified-Since, che però lavora su una data invece che su un'impronta.
Anche Googlebot usa la cache, e quasi nessuno gliela lascia usare
Il 9 dicembre 2024 Gary Illyes ha pubblicato sul blog di Google Search Central un post intitolato Crawling December: HTTP caching con un numero che nessuno si aspettava così basso: dieci anni fa circa lo 0,026% delle richieste totali di Googlebot poteva essere servito dalla cache, oggi si è scesi allo 0,017%. In pratica, praticamente nessun sito dice a Google che una risorsa non è cambiata.
L'infrastruttura di scansione di Google supporta le richieste condizionali esattamente come le descrive la RFC 9111, sia con ETag sia con Last-Modified. Illyes scrive di preferire ETag, perché il valore è una stringa libera e si presta a meno errori di una data formattata a mano, e consiglia di impostarli entrambi quando è possibile. Quando il crawler riceve un 304, il server non genera la pagina e non trasmette il corpo della risposta: risparmia banda e cicli di CPU, e in cambio Google ha più margine per scansionare le pagine che sono davvero cambiate.
Su un sito piccolo la differenza si nota poco. Su un catalogo con decine di migliaia di URL che cambiano di rado, gestire bene le richieste condizionali è uno degli interventi di SEO tecnica con il rapporto migliore tra sforzo e resa, e incide sul modo in cui Google distribuisce le scansioni molto più di parecchi fattori di ranking di cui si discute in continuazione.
La copia cache di Google non esiste più
Metà dei contenuti italiani che parlano di cache spiegano ancora come aprire la «copia cache» di una pagina dalla SERP. Quel link è sparito a gennaio 2024 e la funzione è stata ritirata. Danny Sullivan, Search Liaison di Google, lo ha confermato a Search Engine Land il 1° febbraio 2024, aggiungendo che sarebbe caduto presto anche l'operatore cache:. Oggi quella ricerca non restituisce niente.
Due cose sono sopravvissute. Il meta tag noarchive continua a essere rispettato, come ha precisato Sullivan nello stesso intervento, perché lo leggono anche altri motori. E l'accesso alle versioni storiche è stato spostato fuori casa: dall'11 settembre 2024, come ha annunciato Internet Archive sul proprio blog, cliccando sui tre puntini accanto a un risultato e poi su «Altre informazioni su questa pagina» compare un link alla Wayback Machine.
Per l'uso che ne facevano i SEO, cioè controllare cosa Google ha visto sulla pagina, il sostituto è lo strumento Controllo URL di Google Search Console, che mostra l'HTML scansionato e la data dell'ultima visita. È più preciso della vecchia copia cache, che restituiva una pagina renderizzata e spesso ingannava.
La bfcache, quella di cui non parla quasi nessuno
Il back/forward cache è un'altra cosa rispetto alla cache HTTP: non conserva le singole risposte, conserva l'intera pagina congelata in memoria, heap JavaScript compreso. Quando il visitatore preme il tasto indietro, la pagina ricompare senza toccare la rete.
Quanto pesa lo dice la documentazione di Chrome su web.dev: i dati d'uso di Chrome indicano che 1 navigazione su 10 da desktop e 1 su 5 da mobile sono un indietro o un avanti. Lo hanno Chrome dalla versione 96, Firefox e Safari, e dalla versione 10.0 Lighthouse ha un controllo dedicato.
Il modo più comune di rovinarla è mettere Cache-Control: no-store sull'HTML di tutto il sito per «sicurezza». Quella direttiva storicamente esclude la pagina dalla bfcache. Se il contenuto deve solo restare aggiornato e non è riservato, la scelta giusta è no-cache oppure max-age=0, che impongono la rivalidazione senza bruciare il ritorno indietro istantaneo. L'altra causa classica è un listener sull'evento unload, che Chrome sta deprecando proprio per questo motivo. Il guadagno finisce dritto nelle metriche di page speed e nella percezione di velocità del sito.
Quando la cache diventa il problema
La modifica pubblicata che non si vede è quasi sempre una questione di ordine. Si parte dal livello più interno e si scende: prima la cache di pagina sul server, poi quella degli oggetti se il sito usa Redis o Memcached, poi il purge sulla CDN, e solo alla fine un ricaricamento forzato nel browser. Svuotare la CDN prima del server significa solo ricopiare la versione vecchia nei nodi perimetrali.
Sui file statici il problema si evita prima che nasca, dando a ogni build un nome diverso: style.a3f9c1.css invece di style.css. Un file che cambia nome a ogni rilascio si può tenere in cache per un anno senza rischi, perché la versione nuova è una risorsa nuova. È lo stesso ragionamento che si applica alle immagini ottimizzate, che una volta pubblicate non cambiano quasi mai.
Restano fuori dalla cache di pagina il carrello, il checkout, le aree riservate e qualsiasi schermata che mostri dati di una persona sola. Su WordPress i plugin più diffusi, da WP Rocket a LiteSpeed Cache, hanno già queste esclusioni preimpostate per WooCommerce, ma le pagine costruite a mano con un form o un preventivo dinamico vanno escluse a mano. Un secondo punto di attenzione sono le pagine servite in versioni diverse a seconda di un cookie o della lingua: senza un header Vary corretto, la cache condivisa può consegnare a un visitatore la pagina di un altro.
L'errore di cache che costa più di tutti
Non è una pagina vecchia servita per due ore. È un 301 redirect sbagliato. Lo standard HTTP classifica il 301 come risposta memorizzabile in modo euristico, quindi se il server non allega un Cache-Control esplicito il browser è libero di conservarla a lungo. Tolta la regola dal server, chi l'aveva già incontrata continua a essere reindirizzato dal proprio browser, e il problema è invisibile a chi lo cerca da una macchina pulita. Vale anche al contrario: un errore 404 restituito per sbaglio durante una migrazione può restare in circolo dopo che il sito è tornato a posto.
Chi pubblica redirezioni spesso, per esempio durante il rifacimento di un sito, fa bene ad accompagnare ogni 301 con un Cache-Control: max-age di poche ore finché la mappa non è stabile, e ad alzarlo solo dopo. È un dettaglio che non compare quasi mai nelle checklist di migrazione, e che nei progetti SEO spiega parecchi casi di traffico che non torna quando dovrebbe.
Domande frequenti sulla cache
No. Il purge elimina solo le copie temporanee delle pagine e dei file. I contenuti restano nel database e il sito si ricostruisce da sé alla prima richiesta. L'unico effetto visibile è che il caricamento subito dopo il purge risulta più lento del normale, perché le copie vanno rigenerate.
Google non valuta la presenza di un sistema di cache. Incide però su due cose che contano: i tempi di risposta percepiti dal visitatore e il numero di richieste che Googlebot può chiudere con un 304 Not Modified invece di riscaricare la pagina.
Non a calendario. I plugin di cache invalidano da soli le pagine interessate quando si aggiorna un contenuto. Il purge manuale serve dopo le modifiche che toccano tutto il sito: cambio di tema, interventi sul CSS, aggiornamento di un plugin, nuova build dei file statici.
No. Due plugin che scrivono regole nello stesso file di configurazione del server si sovrascrivono a vicenda e producono pagine servite a metà. Se l'hosting offre già una cache lato server, la scelta è tra quella e il plugin, non entrambe.
Per una pagina qualsiasi si usa la Wayback Machine di Internet Archive, raggiungibile anche dai tre puntini accanto al risultato di ricerca, sotto la voce Altre informazioni su questa pagina. Per una pagina del proprio sito conviene lo strumento Controllo URL di Search Console, che mostra l'HTML effettivamente scansionato e la data dell'ultima visita.
