Configurer mod_expires sous Apache pour un cache navigateur efficace

365 jours pour un fichier qui ne change jamais

365 jours : une durée de cache raisonnable pour une image jamais renommée après publication, bien loin des quelques minutes, voire de l’absence totale d’en-tête d’expiration, souvent laissées par défaut sur un serveur Apache tout juste installé. Le module mod_expires ajoute automatiquement un en-tête Expires (et l’en-tête Cache-Control associé, contenant max-age) à chaque réponse, en calculant la date d’expiration à partir du type MIME du fichier concerné et d’une durée définie dans la configuration.

Sans ce module actif, ou avec une configuration par défaut restée minimaliste, le navigateur d’un visiteur revalide potentiellement chaque fichier statique à chaque nouvelle visite, un aller-retour réseau superflu pour un fichier qui n’a, dans les faits, pas changé depuis des mois.

Différencier les durées par type de fichier

La directive ExpiresByType permet d’attribuer une durée de cache adaptée à chaque type de contenu, plutôt qu’une seule valeur uniforme pour l’ensemble du site :

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType text/html "access plus 0 seconds"
</IfModule>

Cette différenciation reflète une réalité importante sur un site WordPress : les images de médiathèque, une fois publiées, changent rarement de contenu sous une même adresse, ce qui justifie une durée longue d’un an. Les feuilles de style et scripts, en revanche, évoluent au rythme des mises à jour de thème ou d’extensions, ce qui justifie une durée plus modérée. Le contenu HTML lui-même, généré dynamiquement à chaque requête sur WordPress, ne doit jamais recevoir d’en-tête d’expiration, sous peine d’afficher un contenu figé pendant une durée non souhaitée.

Contourner le vrai problème du changement de contenu

Une durée de cache longue pose une question légitime : que se passe-t-il si le contenu d’un fichier change réellement, par exemple après le remplacement d’une image ou la mise à jour d’une feuille de style ? La réponse la plus robuste ne consiste pas à raccourcir la durée de cache par prudence, ce qui annulerait le bénéfice recherché, mais à changer l’adresse du fichier lui-même lors de chaque modification, une pratique déjà largement répandue via un numéro de version ajouté à l’adresse des feuilles de style et scripts par WordPress lui-même, ou via un nom de fichier différent pour chaque nouvelle version d’une image.

<link rel="stylesheet" href="/wp-content/themes/mon-theme/style.css?ver=6.2.3">

Avec ce paramètre de version dans l’adresse, une nouvelle valeur force le navigateur à télécharger une copie fraîche, sans jamais avoir besoin de raccourcir la durée de cache globale du site pour anticiper un changement futur incertain.

Pièges fréquents

• Appliquer une durée d’un an uniforme à tous les types de fichiers, y compris au contenu HTML généré dynamiquement, ce qui fige des pages qui devraient au contraire toujours rester à jour
• Oublier que mod_expires doit être activé sur le serveur (a2enmod expires sous Debian ou Ubuntu) avant que la configuration ne produise le moindre effet, une étape parfois oubliée lors d’une migration de serveur
• Configurer une durée longue sans mécanisme de changement d’adresse à la modification, ce qui contraint un visiteur à conserver une ancienne version bien après sa mise à jour réelle sur le serveur

Vérifier l’en-tête réellement renvoyé

Une simple requête avec les en-têtes affichés confirme la présence et la valeur exacte de l’en-tête Expires pour un fichier donné, une vérification à effectuer systématiquement après toute modification de cette configuration, plutôt que de supposer son bon fonctionnement sans confirmation directe.

curl -I https://exemple.fr/wp-content/uploads/2022/08/photo.jpg

En résumé

Un fichier statique qui ne change jamais de contenu n’a aucune raison d’être redemandé au serveur à chaque visite, seulement d’être redemandé le jour où son adresse change réellement.

Différencier les durées de cache par type de fichier avec ExpiresByType, tout en combinant cette approche à un changement d’adresse systématique lors des mises à jour, offre un cache navigateur à la fois efficace et sans risque de contenu obsolète affiché par erreur.