Cache del browser

Perché la cache

La cache HTTP permette al browser (e ai CDN intermedi) di riutilizzare risposte già scaricate. Per visitatori abituali riduce latenza e consumo dati. Strategia tipica: cache lunga per asset statici immutabili (CSS/JS con hash nel nome, font, icone) e cache brevi o no-cache per HTML dinamico e JSON che cambia spesso.

Header Cache-Control

Valori comuni: public, max-age=31536000, immutable per file versionati; no-cache o max-age=0, must-revalidate per documenti HTML personalizzati. ETag e Last-Modified abilitano revalidazione condizionale (304) quando la cache scade ma il file è invariato.

# Asset statico versionato
Cache-Control: public, max-age=31536000, immutable

# Pagina HTML dinamica
Cache-Control: no-cache

Versionare gli asset

Ad ogni deploy cambia query string o hash nel filename. Il HTML punta al nuovo URL; i client scaricano fresh copy mentre vecchie versioni restano in cache senza conflitto.

<link rel="stylesheet" href="/css/site.a3f9c2.css">
<script src="/js/app.b7e1d0.js" defer></script>

HTML e API

Non mettere cache aggressiva su pagine con login o carrello. API sensibili: private, no-store se contengono dati personali. Service worker (se presente) segue regole diverse: coordina con header di rete per evitare staleness.

CDN e compressione

Abilita Brotli o gzip per text assets. Imposta Vary corretto se servi versioni per Accept-Encoding o lingua. Purge CDN selettivo quando cambi solo HTML, non invalidare tutto il grafo asset. Service worker account: strategia stale-while-revalidate per CSS può accelerare repeat visit senza bloccare update se hash cambia.

Log 304 vs 200 per capire se revalidation funziona.

Per consolidare quanto hai letto, scegli due pagine reali del tuo sito e applica gli stessi criteri con il team: una modifica alla volta, verifica su mobile e annota nel registro interno data e responsabile. Così la lezione diventa pratica ricorrente e non un intervento una tantum prima di una campagna.

Verifica periodica

Programma ogni trimestre un controllo su pagine ad alto traffico: applica i criteri di Cache del browser con la stessa procedura (browser, dispositivo, rete). Registra esito e responsabile in un foglio condiviso così il team non riparte da zero.

Se hai appena cambiato tema, plugin o builder, ripeti il controllo dopo 48 ore: cache CDN e minificazione possono mascherare errori finché non scade la vecchia versione. Coinvolgi chi scrive i contenuti, non solo chi sviluppa: molti problemi nascono da campi CMS lasciati vuoti.

Confronta i risultati con una pagina concorrente solo per capire gap di chiarezza, non per copiare testi. L’obiettivo è che un visitatore capisca in pochi secondi cosa offri e come contattarti.

Errori comuni

• max-age anno su HTML.
• Hash dimenticato nel pipeline di build.
• CDN che sovrascrive header corretti del origin.
• Query ?v= uguale per mesi di deploy.
• Cache bust manuale «chiedi agli utenti Ctrl+F5».

In pratica, integra questo controllo nella routine di qualità del sito: una pagina campione al mese per categoria (home, servizio, articolo, checkout se presente), stesso profilo browser e rete. Annota nel registro interno data verifica e esito, così al prossimo redesign sai cosa è già stato validato. Quando il team cresce, una checklist condivisa evita che ognuno interpreti i criteri in modo diverso e riduce regressioni dopo deploy frettolosi.

Quando lavori con clienti o stakeholder non tecnici, traduci ogni raccomandazione in un esempio concreto sulla loro pagina: uno screenshot prima/dopo, una URL di prova, un tempo di caricamento misurato. Così le lezioni diventano azioni nel backlog invece di slide dimenticate. Riutilizza gli stessi criteri su ambienti preview prima della produzione e registra chi ha approvato il go-live, per tracciabilità in caso di regressione SEO o accessibilità.

Tieni un elenco di URL di riferimento nel tuo progetto e riapplicalo dopo ogni modifica al tema o al CMS, così non devi ricordare a memoria ogni regola.

Segna in calendario una revisione trimestrale: venti minuti bastano per confermare che template e plugin non abbiano reintrodotto errori già corretti.

In breve

• Lunga cache solo su file versionati.
• HTML/API: revalidate o no-store.
• Hash o query al deploy.
• Verifica header reali in prod.