Che cos'è l'invalidazione della cache CDN

Introduzione al caching CDN

Una Content Delivery Network (CDN) funziona memorizzando copie dei tuoi contenuti su server edge in tutto il mondo e servendoli agli utenti dal server più vicino, anziché far transitare ogni richiesta verso il tuo server di origine. Questo riduce drasticamente la latenza e accelera il caricamento del sito per gli utenti, indipendentemente da dove si trovino. Tuttavia, il caching porta con sé una sfida fondamentale: come garantire che gli utenti vedano sempre l'ultima versione dei contenuti quando apporti modifiche al sito.

L'invalidazione della cache è il processo di rimozione o sostituzione dei contenuti obsoleti dalla cache della CDN. Phil Karlton disse una volta che nell'informatica esistono solo due cose davvero difficili: dare un nome alle cose e l'invalidazione della cache. Questa affermazione illustra alla perfezione quanto sia complessa la gestione della cache, perché ogni decisione sbagliata può portare gli utenti a vedere contenuti obsoleti oppure a sovraccaricare inutilmente il server di origine quando la cache viene svuotata in modo troppo aggressivo.

Come funziona la cache CDN

Quando un utente richiede per la prima volta una risorsa che non è in cache, la CDN inoltra la richiesta al server di origine, ottiene la risposta e ne memorizza una copia sul proprio server edge. Ogni richiesta successiva per la stessa risorsa dallo stesso server edge viene servita direttamente dalla cache, senza contattare l'origine. Il server di origine controlla il comportamento della cache tramite header HTTP come Cache-Control, Expires, ETag e Last-Modified.

Header HTTP chiave per il caching

• Cache-Control: max-age=3600 - la risorsa è fresca per i prossimi 3600 secondi (1 ora)
• Cache-Control: s-maxage=86400 - specifico per le cache condivise (CDN), ha priorità su max-age
• Cache-Control: no-cache - la cache deve rivalidare con l'origine prima di servire
• Cache-Control: no-store - la risorsa non deve mai essere messa in cache
• ETag - identificatore univoco della versione della risorsa per la rivalidazione
• Vary - determina in base a quali header differiscono le versioni in cache

Comprendere questi header è fondamentale, perché definiscono le regole con cui la CDN decide se servire la versione in cache o richiederne una nuova dal server di origine. Header configurati in modo errato sono la causa più comune dei problemi con contenuti obsoleti o di richieste inutilmente frequenti all'origine.

Cache purging - svuotamento manuale della cache

Il cache purging è il modo più diretto per rimuovere contenuti dalla cache CDN. La maggior parte dei provider CDN offre API e dashboard per attivare manualmente le operazioni di purge. Puoi svuotare un singolo URL, un gruppo di URL secondo un pattern (wildcard purge) o l'intera cache di tutte le risorse. Ogni approccio ha vantaggi e svantaggi a seconda della situazione.

Tipi di operazioni di purge

Il purge di un singolo URL è il metodo più preciso e veloce perché prende di mira esattamente una risorsa. Usalo quando aggiorni una singola pagina o un file. Il wildcard purge elimina tutte le risorse che corrispondono a un certo pattern, ad esempio /blog/* elimina dalla cache tutte le pagine del blog. È utile quando aggiorni un numero elevato di pagine ma non vuoi svuotare l'intera cache. Il full purge elimina assolutamente tutto dalla cache e dovrebbe essere usato solo in situazioni urgenti, perché aumenta temporaneamente il carico sul server di origine mentre la cache viene ricostruita.

Le operazioni di purge si propagano di solito attraverso la rete CDN in un intervallo da 1 a 30 secondi, a seconda del provider e delle dimensioni della rete. Il purge della rete Cloudflare si propaga a livello globale in circa 30 secondi, mentre AWS CloudFront può richiedere fino a 15 minuti per le invalidazioni wildcard. Tieni sempre presente questo ritardo quando apporti modifiche in produzione e verifichi se la nuova versione è visibile.

Strategie TTL

Il Time-To-Live (TTL) determina per quanto tempo la CDN considera fresco il contenuto in cache prima di richiedere una nuova versione all'origine. Impostare correttamente il TTL è un equilibrio tra prestazioni (TTL più lungo = meno richieste all'origine) e freschezza dei contenuti (TTL più breve = modifiche visibili più rapidamente). Non esiste un TTL universalmente corretto, perché dipende dal tipo di contenuto e dalla frequenza con cui cambia.

TTL consigliati per tipo di contenuto

• Asset statici (JS, CSS, font) - 1 anno (31536000s) con versioning dei file
• Immagini - 30 giorni (2592000s) con rivalidazione ETag
• Pagine HTML - da 5 minuti a 1 ora a seconda dei contenuti dinamici
• Risposte API - da 0 a 60 secondi a seconda dei dati
• Favicon e robots.txt - 1 giorno (86400s)

La direttiva stale-while-revalidate è una strategia eccellente che consente alla CDN di servire agli utenti contenuti obsoleti mentre, contemporaneamente, richiede una nuova versione all'origine in background. Questo significa che l'utente non attende mai il server di origine, ma vedrà la nuova versione alla richiesta successiva. Ad esempio, Cache-Control: max-age=60, stale-while-revalidate=3600 significa che il contenuto è fresco per 60 secondi, ma può essere servito dalla cache per l'ora successiva mentre viene aggiornato in background.

Versioning delle risorse

Il versioning delle risorse è la strategia più elegante per risolvere il problema dell'invalidazione della cache, perché elimina completamente la necessità di operazioni di purge esplicite. Invece di cambiare il contenuto del file allo stesso URL, ogni nuova versione riceve un nuovo URL, il che significa che la CDN serve automaticamente la nuova versione perché la tratta come una risorsa completamente nuova non ancora presente in cache.

Metodi di versioning

L'hash del contenuto nel nome del file è il metodo più diffuso. Strumenti di build come Webpack, Vite e Next.js aggiungono automaticamente l'hash del contenuto al nome del file, ad esempio style.a1b2c3d4.css. Quando il CSS cambia, l'hash cambia e viene generato un nuovo file con un nuovo nome. La vecchia versione rimane in cache ma nessuno la referenzia più, perché ora l'HTML punta al nuovo file.

Il versioning tramite query string (style.css?v=1.2.3) è un approccio più semplice ma meno affidabile, perché alcuni provider CDN ignorano le query string durante il caching. Usalo solo se non puoi cambiare il nome del file. Il versioning tramite path (/v2/style.css) è un'altra opzione che funziona in modo affidabile con tutti i provider CDN ma richiede più configurazione sul server.

Quando invalidare la cache

Sapere quando invalidare la cache è importante tanto quanto sapere come farlo. Gli scenari più comuni che richiedono l'invalidazione includono il deploy di una nuova versione del sito sul server di hosting, la correzione di un errore critico nei contenuti, la rimozione di contenuti sensibili pubblicati per errore e la modifica di prezzi o disponibilità dei prodotti in un negozio e-commerce. In tutti questi casi, gli utenti devono vedere i contenuti aggiornati il prima possibile.

Best practice di invalidazione

• Automatizza - integra il purge della cache nella pipeline CI/CD per un'invalidazione automatica a ogni deploy
• Sii preciso - prendi di mira URL specifici invece del full purge ogni volta che è possibile
• Usa il versioning - per gli asset statici elimina completamente la necessità di invalidazione manuale
• Monitora - tieni traccia del cache hit ratio per individuare problemi di configurazione
• Testa - verifica gli header con curl -I per confermare che il caching funzioni come previsto
• Documenta - registra i valori TTL e la strategia di invalidazione per ogni tipo di contenuto

Problemi comuni e soluzioni

Uno dei problemi più comuni è il cosiddetto stale content, in cui gli utenti vedono contenuti obsoleti nonostante le modifiche apportate sul server di origine. La causa è di solito un TTL troppo lungo senza un meccanismo di invalidazione. La soluzione è la combinazione di un TTL ragionevole con operazioni di purge automatizzate al deploy. Un altro problema comune è il cache stampede, in cui dopo la scadenza del TTL per una risorsa popolare, centinaia di richieste concorrenti colpiscono simultaneamente il server di origine. La soluzione è il request coalescing, in cui la CDN invia una sola richiesta all'origine mentre trattiene tutte le altre richieste fino a ricevere la risposta.

Il problema di versioni diverse dei contenuti su server edge diversi (cache inconsistency) nasce perché un'operazione di purge non può propagarsi a tutti i server simultaneamente. Durante il breve periodo successivo al purge, alcuni utenti vedranno la vecchia versione e altri la nuova. Per le modifiche critiche, usa il meccanismo di versioning degli URL che garantisce la coerenza, perché ogni utente accede a una versione della risorsa definita in modo esatto.