# Une police auto-hébergée jamais mise à jour : le Cache-Control immutable en jeu

> Ajouter la directive immutable aux fichiers de police déjà versionnés par une empreinte dans leur nom économise des revalidations HTTP totalement inutiles.

- Auteur : WordPress Développement
- Publié le : 2021-10-18
- Mis à jour le : 2021-10-18
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/police-auto-hebergee-cache-control-immutable/

## L’essentiel

- Un fichier versionné par son nom ne change jamais de contenu
- immutable évite au navigateur de revérifier ce qui ne peut pas avoir changé
- La directive s'ajoute sans risque uniquement sur des fichiers correctement versionnés

`Cache-Control: public, max-age=31536000, immutable` — cette ligne d'en-tête, ajoutée aux fichiers de police auto-hébergés d'un thème WordPress, élimine une catégorie entière de requêtes HTTP jusque-là considérées comme normales : les requêtes de revalidation envoyées par le navigateur pour vérifier qu'un fichier déjà en cache local n'a pas changé.

Le principe repose sur une convention déjà en place sur ce projet : chaque fichier de police est nommé avec une empreinte de hachage de son contenu, par exemple `inter-var-a1b2c3d4.woff2`. Si le contenu du fichier change, un nouveau déploiement génère un nouveau nom de fichier, avec une nouvelle empreinte. Le fichier portant l'ancien nom, lui, ne changera plus jamais de contenu tant qu'il existe.

## Pourquoi une revalidation classique est un gaspillage ici

Sans la directive `immutable`, même avec un `max-age` très long, un navigateur peut malgré tout envoyer une requête conditionnelle (avec un en-tête `If-None-Match` ou `If-Modified-Since`) lors d'un rechargement forcé de la page par l'utilisateur, ou selon sa propre heuristique interne de fraîcheur perçue. Le serveur répond alors par un code 304, plus léger qu'un téléchargement complet, mais qui reste un aller-retour réseau totalement superflu pour un fichier dont le contenu ne peut structurellement pas avoir changé.

## Mise en œuvre côté serveur

```
# Extrait de configuration nginx pour les fichiers de police versionnés
location ~* \.(woff2)$ {
    if ($request_uri ~* "-[0-9a-f]{8}\.woff2$") {
        add_header Cache-Control "public, max-age=31536000, immutable";
    }
}
```

> L'essentiel à retenir : Un fichier versionné par son nom ne change jamais de contenu ; immutable évite au navigateur de revérifier ce qui ne peut pas avoir changé ; La directive s'ajoute sans risque uniquement sur des fichiers correctement versionnés

## Le piège à éviter absolument

Appliquer `immutable` à un fichier dont le nom ne change jamais, alors même que son contenu peut être remplacé lors d'une mise à jour (un fichier `style.css` classique par exemple), garantit que certains navigateurs continueront d'afficher l'ancienne version pendant toute la durée du `max-age`, sans jamais revérifier, même après un rechargement forcé par l'utilisateur. Cette directive n'a de sens que couplée à un système de nommage qui garantit qu'un changement de contenu produit systématiquement un changement de nom de fichier.

### Vérifier la compatibilité navigateur avant de généraliser

Le support de `immutable` reste inégal selon les navigateurs et leurs versions ; ceux qui ne le reconnaissent pas l'ignorent simplement et retombent sur le comportement standard basé sur `max-age`, sans erreur ni régression visible. La directive s'ajoute donc sans risque, mais son bénéfice réel varie selon le parc de navigateurs des visiteurs du site.

## Étendre la pratique à d'autres ressources

- Fichiers JavaScript et CSS compilés avec une empreinte dans le nom, générés par un outil de build.
- Images optimisées et versionnées automatiquement lors de leur import dans la médiathèque, si le thème le prévoit.
- Toute ressource statique dont le pipeline de déploiement garantit un renommage systématique en cas de modification du contenu.

## Mesurer l'effet sur un parcours de navigation répété

Pour objectiver le gain, l'équipe a comparé le nombre de requêtes réseau déclenchées par le navigateur lors de la navigation entre cinq pages successives du site, avant et après l'ajout de la directive. Sans `immutable`, les outils de développement montraient systématiquement une requête conditionnelle par police à chaque nouvelle page, résolue par un code 304 en quelques millisecondes mais bien présente dans le journal réseau. Après l'ajout de la directive, ces requêtes disparaissaient purement et simplement du journal réseau à partir de la deuxième page visitée, le navigateur se fiant entièrement à sa copie locale sans solliciter le serveur.

### Étendre la vérification à l'outil de build

Pour garantir que la convention de nommage reste respectée dans la durée, il est utile d'ajouter une vérification automatisée dans le pipeline de build du thème, qui échoue explicitement si un fichier de police est référencé sans empreinte de hachage dans son nom, avant même que ce fichier n'atteigne la configuration serveur.

## En résumé

La directive `immutable` ne change rien à la fraîcheur théorique d'une ressource : elle indique simplement au navigateur qu'il peut faire confiance à cette fraîcheur sans jamais la revérifier, ce qui n'est sûr que pour des fichiers dont le nom encode directement le contenu. Sur des polices auto-hébergées correctement versionnées, c'est une optimisation à coût nul et sans risque.