Le WordPress d'aujourd'hui, décodé pour les développeurs

Performance

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.

Par WordPress Développement • 18 octobre 2021 • 4 min de lecture • Aucun commentaire
Une police auto-hébergée jamais mise à jour : le Cache-Control immutable en jeu

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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi