Hai aggiornato il sito, ma il cliente continua a vedere la versione vecchia. Frustrante, vero? Quasi sempre il colpevole è la cache del browser. La buona notizia è che esiste una tecnica precisa per risolverlo: il cache busting. Vediamo come funziona.
Perché esiste la cache
Per andare veloce, il browser salva una copia locale dei file di un sito (immagini, fogli di stile, JavaScript). Alla visita successiva li riusa invece di riscaricarli: pagine più rapide e meno traffico. È un'ottima cosa... finché non pubblichi una modifica.
Il problema: file vecchi serviti dal browser
Se il nome del file non cambia, il browser pensa di avere già la versione giusta e continua a mostrare quella vecchia. Il risultato: aggiornamenti che "non si vedono" senza svuotare manualmente la cache — cosa che nessun utente farà.
Soluzione 1: la query string di versione
Si aggiunge al file un parametro che cambia a ogni modifica:
<link rel="stylesheet" href="/css/base.css?v=1718031040">
<script src="/js-build/app.js?v=1718031040"></script>Quando il numero cambia, il browser considera il file "nuovo" e lo riscarica. È leggero e immediato.
Soluzione 2: l'hash nel nome del file
In alternativa, lo strumento di build inserisce nel nome del file un codice che dipende dal contenuto (es. app.9f3a2c.js). Se il contenuto cambia, cambia il nome, e la cache vecchia diventa irrilevante. È l'approccio più robusto per la produzione.
Il limite del cache busting
Il meccanismo protegge gli asset referenziati, non il documento che li referenzia. Se anche l'HTML viene messo in cache a lungo, il browser continua a servire la pagina vecchia con i vecchi URL versionati e l'aggiornamento non arriva mai. La configurazione corretta è asimmetrica: HTML con cache breve e rivalidazione (ETag), asset versionati con cache lunga e immutabile.
Collegato: minificazione e offuscamento e git come rete di sicurezza.