Mettere in cache i file statici è la velocità più economica che esista: il browser non chiede proprio nulla. Il rischio è quello opposto — un foglio di stile tenuto in cache per un anno che poi devi cambiare, su una macchina che non puoi raggiungere.

La regola che rende sicura una cache lunga

Metti in cache in modo aggressivo SOLO i file il cui nome cambia quando cambia il contenuto. Allora una modifica è un nome nuovo, la cache vecchia non conta più, e nessun visitatore si ritrova mai in mano il file sbagliato.

/css/site.a1b2c3.css        <- safe to cache for a year
/css/site.css?v=1788541047   <- the same idea, from the file mtime

Che cosa impostare

location ~* \.(css|js|woff2|jpg|png|webp|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

location ~* \.(html|php)$ {
    add_header Cache-Control "no-cache";
}

immutable dice al browser di non riconvalidare nemmeno. no-cache sull'HTML non significa «non mettere in cache»: significa «chiedimelo prima», ed è esattamente ciò che serve a una pagina il cui contenuto cambia senza che cambi il suo indirizzo.

Non tenere mai a lungo in cache un file dal nome stabile. /css/site.css conservato per un anno è un anno di visitatori sul vecchio design, e dal tuo lato non c'è nulla che tu possa fare per accorciarlo.

Controlla che cosa stai mandando

curl -sI https://yourdomain.com/css/site.css | grep -iE "cache-control|expires|etag"

ETag e Last-Modified

Questi rendono economico il CONTROLLO, non superflua la richiesta: il browser chiede, il server risponde 304 Not Modified, e non viene mandato alcun corpo. Buoni per l'HTML, e per le risorse la seconda scelta migliore dopo il non chiedere affatto.

Dietro una CDN, ricordati che le cache sono due. Svuotare la CDN non arriva a un browser che quel file ce l'ha per un anno — ed è proprio per questo che il nome deve cambiare.