Exploiter la mise en cache dans le navigateur (Leverage browser caching)

Les outils de mesure de chargement de sites Web comme GTMetrix ou Google PageSpeed Insights nous répliquent systématiquement ceci : Leverage browser caching.

En définissant une date d'expiration ou une durée de validité maximale pour les ressources statiques dans les en-têtes HTTP, vous indiquez au navigateur d'aller chercher les ressources déjà téléchargées sur le disque local plutôt que sur le réseau.

Explications : https://gtmetrix.com/leverage-browser-caching.html

Cela peut se faire dans le .htaccess ou avec un plugin WordPress.

« Leverage browser caching » est l'ancien libellé, hérité de l'ancien PageSpeed ; GTmetrix range d'ailleurs sa page explicative dans sa rubrique « PageSpeed (Legacy) ». Le conseil a ensuite été renommé « Serve static assets with an efficient cache policy », puis, dans les versions récentes de Lighthouse (le moteur de PageSpeed Insights), « Utiliser des durées de mise en cache efficaces » (« Use efficient cache lifetimes » en anglais). Le problème est le même : certains fichiers de votre site sont envoyés sans durée de conservation, ou avec une durée trop courte.

Concrètement, le serveur doit accompagner chaque image, feuille de style, script ou police d'un en-tête HTTP Cache-Control (avec une durée max-age) ou Expires. Le navigateur garde alors ces fichiers pendant la durée indiquée et ne les retélécharge pas à la visite suivante. Le gain concerne surtout les visiteurs qui reviennent ou qui consultent plusieurs pages. Google détaille le principe dans sa documentation sur la durée de vie du cache.

C'est la solution la plus simple, et souvent la seule nécessaire :

• WP Rocket ajoute des règles de cache navigateur dans le fichier .htaccess dès son activation, sur un serveur Apache. Sur Nginx, il ne peut pas modifier la configuration lui-même : il faut ajouter manuellement les règles fournies dans sa documentation. Voir l'avis sur WP Rocket.

• FlyingPress définit automatiquement de longues durées de cache pour les fichiers statiques sur les serveurs Apache, LiteSpeed et OpenLiteSpeed. Sur Nginx, sa documentation renvoie vers votre hébergeur ou une modification de la configuration. Voir l'avis sur FlyingPress.

• LiteSpeed Cache, gratuit, propose une option « Browser Cache » qui est désactivée par défaut : activez-la dans les réglages Cache de l'extension. La durée recommandée par l'éditeur est de 31 557 600 secondes, soit un an.

Les autres solutions sont comparées dans la page meilleurs plugins de cache et de performance.

Sans plugin, vous pouvez ajouter ces règles dans le fichier .htaccess à la racine du site, en dehors du bloc compris entre # BEGIN WordPress et # END WordPress (WordPress réécrit ce bloc). Faites une copie du fichier avant de le modifier.

Le module Apache mod_expires génère à la fois l'en-tête Expires et la durée max-age de l'en-tête Cache-Control (documentation Apache). Le bloc IfModule évite une erreur si le module n'est pas activé chez votre hébergeur.

Une durée d'un an pour les CSS et JavaScript n'est pas un risque dans la plupart des cas : WordPress ajoute en général un numéro de version (?ver=...) à l'adresse des fichiers des thèmes et des extensions, qui change à chaque mise à jour. Si vous modifiez vous-même un fichier CSS sans changer ce numéro, en revanche, les visiteurs réguliers peuvent garder l'ancienne version quelque temps.

Nginx n'utilise pas le fichier .htaccess. Les en-têtes de cache se règlent dans la configuration du serveur, à laquelle vous n'avez généralement pas accès sur un hébergement géré. Demandez au support de votre hébergeur, ou cherchez l'option correspondante dans son tableau de bord : beaucoup d'hébergeurs WordPress configurent déjà ces en-têtes.

Si votre site passe par Cloudflare, le réglage Browser Cache TTL (page Caching du tableau de bord) agit aussi sur ces en-têtes. Par défaut, Cloudflare respecte les en-têtes envoyés par votre serveur. La valeur choisie dans le tableau de bord ne les remplace que si votre serveur n'envoie aucun en-tête de cache, ou une durée plus courte. La documentation de WP Rocket recommande une durée d'un an sur Cloudflare pour éviter l'avertissement dans GTmetrix.

L'alerte persiste souvent pour des fichiers chargés depuis d'autres domaines : Google Analytics, pixels publicitaires, vidéos YouTube intégrées, polices externes, widgets de chat. Leur durée de cache est fixée par le service qui les fournit, et aucun réglage de votre côté ne peut la changer. Si ces fichiers sont les seuls signalés, votre travail est fait. Pour réduire leur impact, la seule piste est d'en charger moins (polices hébergées localement, vidéos chargées au clic...).

Relancez un test dans PageSpeed Insights ou GTmetrix après avoir vidé le cache de votre plugin et de Cloudflare. Les fichiers de votre domaine ne doivent plus apparaître dans la liste. Vous pouvez aussi ouvrir les outils de développement du navigateur (onglet Réseau), cliquer sur une image et vérifier la présence de l'en-tête cache-control avec une valeur max-age.

Pour replacer ce réglage parmi les autres leviers (hébergement, images, cache de page), voyez la page Performances WordPress.