Mettre en cache les fichiers statiques est la vitesse la moins chère qui soit : le navigateur ne demande rien du tout. Le risque est l'inverse — une feuille de style mise en cache pour un an que vous devez ensuite modifier, sur une machine que vous ne pouvez pas atteindre.

La règle qui rend le cache long sans danger

Mettez en cache agressivement UNIQUEMENT les fichiers dont le nom change quand leur contenu change. Alors une modification est un nom nouveau, l'ancien cache n'a plus d'importance, et aucun visiteur ne détient jamais le mauvais fichier.

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

Que poser

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 dit au navigateur de ne même pas revalider. no-cache sur du HTML ne veut pas dire « ne pas mettre en cache » : cela veut dire « vérifie auprès de moi d'abord », et c'est exactement ce qu'il faut pour une page dont le contenu change sans que son adresse change.

Ne mettez jamais longtemps en cache un fichier au nom stable. /css/site.css gardé un an, c'est un an de visiteurs sur l'ancienne maquette, et vous ne pouvez rien faire de votre côté pour raccourcir ce délai.

Vérifiez ce que vous envoyez

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

ETag et Last-Modified

Ceux-là rendent la VÉRIFICATION bon marché au lieu de rendre la requête inutile : le navigateur demande, le serveur répond 304 Not Modified, et aucun corps n'est envoyé. Bien pour le HTML, et deuxième meilleur choix après ne rien demander du tout pour les ressources.

Derrière un CDN, souvenez-vous qu'il y a deux caches. Purger le CDN n'atteint pas un navigateur qui garde le fichier un an — et c'est la raison pour laquelle le nom doit changer.