Comment réparer l’avertissement « Specify a cache validator » ?

Vous voyez l’avertissement « Specify a cache validator » dans Pingdom, GTmetrix, ou Google PageSpeed Insights sur votre site WordPress ? Ceci est dû à l’absence d’en-têtes de mise en cache HTTP qui doivent être inclus dans chaque réponse du serveur d’origine, car ils valident et définissent la longueur du cache. Si les en-têtes ne sont pas trouvés, une nouvelle requête pour la ressource sera générée à chaque fois, ce qui augmente la charge sur votre serveur. L’utilisation d’en-têtes de mise en cache garantit que les requêtes ultérieures n’ont pas à être chargées à partir du serveur, ce qui permet d’économiser de la bande passante et d’améliorer les performances de l’utilisateur.

L’avertissement de Pingdom dit :

Il manque un validateur de cache aux ressources suivantes. Les ressources qui ne spécifient pas de validateur de cache ne peuvent pas être actualisées efficacement. Spécifiez un en-tête Last-Modified ou ETag pour activer la validation du cache pour les ressources suivantes.

Suivez les étapes ci-dessous pour corriger l’avertissement « Specify a cache validator ».

Correction de l’avertissement « Specify a cache validator ».

La première chose qu’il est important de noter à propos de cet avertissement est que vous ne pouvez le corriger que pour les requêtes qui sont sur votre serveur. Si vous avez des requêtes de tierces parties sur lesquelles vous voyez cela, il n’y a rien que vous puissiez faire car vous n’avez pas de contrôle sur leurs serveurs web. N’hésitez pas à partager cet article avec eux. Et rappelez-vous qu’avec Pingdom, vous devrez peut-être faire le test plusieurs fois. Il se peut que l’avertissement apparaisse la première fois et disparaisse la deuxième fois. Lorsque vous exécutez l’outil pour la première fois, il amorce le cache des ressources à partir du serveur.

Il existe quatre types différents d’en-têtes qui peuvent être utilisés de différentes manières pour corriger cet avertissement. C’est là que ça peut devenir un peu confus, mais nous allons essayer de l’expliquer aussi facilement que possible.

En-têtes qui valident le cache

Les deux premiers en-têtes sont les Last-Modified et ETag. Ces en-têtes aident le navigateur à déterminer si le fichier a changé depuis la dernière fois qu’il a été demandé. Ou plutôt, ils valident le cache.

1. Last-Modified

L’en-tête Last-Modified est généralement envoyé automatiquement depuis le serveur. C’est un en-tête que vous n’aurez généralement pas besoin d’ajouter manuellement. Il est envoyé pour voir si le fichier dans le cache du navigateur a été modifié depuis la dernière fois qu’il a été demandé. Vous pouvez consulter la requête d’en-tête dans Pingdom ou utiliser Chrome DevTools pour voir la valeur de l’en-tête Last-Modified.

2. ETag

L’en-tête ETag est également très similaire à l’en-tête Last-Modified. Il sert également à valider le cache d’un fichier. Si vous utilisez Apache 2.4 ou supérieur, l’en-tête ETag est déjà automatiquement ajouté en utilisant la directive FileETag. Et en ce qui concerne NGINX, depuis 2016, l’en-tête ETag est activé par défaut.

Vous pouvez activer manuellement l’en-tête ETag dans NGINX en utilisant le code suivant.

etag on

En-têtes qui déterminent la longueur du cache

Les deux en-têtes suivants sont Cache-Control et Expires. Ces en-têtes aident à déterminer combien de temps le fichier doit être conservé en cache avant qu’il ne récupère une nouvelle copie sur le serveur. Rappelez-vous, pour corriger les avertissements que vous voyez dans Pingdom ou GTmetrix, vous devez vous assurer que vous avez un en-tête qui valide à la fois le cache, ainsi qu’un qui détermine la longueur du cache.

3. Cache-Control

Cache-Control est un en-tête composé de différentes directives qui vous permettent de définir la longueur du cache. Quelques-unes des directives les plus courantes sont les suivantes :

• max-age : Définit la durée pendant laquelle un fichier doit être mis en cache.
• public : Permet à n’importe quel cache de stocker publiquement la réponse.
• private : Ne peut être mis en cache que par le navigateur qui accède au fichier.

Dans notre exemple ci-dessus, nous pouvons voir que la ressource utilise la directive max-age. 604800 secondes équivaudrait à un cache de sept jours. Pour configurer ceci dans Apache, ajoutez simplement le code suivant à votre fichier .htaccess.

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=604800, public"

Pour configurer ceci dans NGINX, ajoutez simplement le code suivant à votre fichier de configuration. Tous les fichiers de configuration NGINX se trouvent dans le répertoire /etc/nginx/Le fichier de configuration principal est /etc/nginx/nginx.conf.

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
 add_header Cache-Control "public";
}

Pour en savoir plus sur les différentes directives, consultez cet article détaillé sur Cache-Control .

4. Expire

Et en dernier, vous avez l’en-tête expires. Selon cet article de Google Developers, HTTP Caching : Cache-Control header a été défini dans le cadre de la spécification HTTP/1.1 et remplace les en-têtes précédents (dans ce cas l’en-tête Expires) utilisés pour définir les politiques de cache des réponses. Tous les navigateurs modernes supportent le Cache-Control, c’est donc tout ce dont vous avez besoin. Cependant, cela ne fera pas de mal si vous avez les deux, mais rappelez-vous qu’un seul sera utilisé. L’en-tête Expires utilise une date réelle, tandis que l’en-tête Cache-Control vous permet de spécifier un délai avant expiration.

Pour ajouter l’en-tête Expires dans Apache, ajoutez simplement le code suivant à votre fichier .htaccess.

## EXPIRES HEADER CACHING ##
 
 ExpiresActive On
 ExpiresByType image/jpg "access 1 year"
 ExpiresByType image/jpeg "access 1 year"
 ExpiresByType image/gif "access 1 year"
 ExpiresByType image/png "access 1 year"
 ExpiresByType text/css "access 1 month"
 ExpiresByType application/pdf "access 1 month"
 ExpiresByType application/javascript "access 1 month"
 ExpiresByType application/x-javascript "access 1 month"
 ExpiresByType application/x-shockwave-flash "access 1 month"
 ExpiresByType image/x-icon "access 1 year"
 ExpiresDefault "access 7 days"
 
 ## EXPIRES HEADER CACHING ##

Assurez-vous d’ajouter le bloc d’en-têtes Expires sous des éléments tels que mod_rewrite, GZIP, etc. Le bas du fichier se trouve être le plus sûr.

Pour ajouter les en-têtes Expires dans NGINX, ajoutez simplement le code suivant à votre fichier de configuration.

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 7d;
}

Dans de nombreux cas sur NGINX, l’en-tête Cache-Control et l’en-tête Expires sont simplement utilisés ensemble, même si ce n’est pas techniquement nécessaire :

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 7d;
    add_header Cache-Control "public";
}

Tous les en-têtes ci-dessus sont ajoutés par défaut sur tous les serveurs Kinsta, donc si vous êtes un client Kinsta, vous ne verrez jamais cet avertissement et n’aurez pas à vous inquiéter. La plupart des fournisseurs de CDN tiers, tels que KeyCDN et Cloudflare, ajoutent également automatiquement ces en-têtes lors de la livraison de vos ressources. Si vous voyez les avertissements, il se peut que votre hébergeur n’ait plus de logiciel à jour ou qu’il ait mal configuré le serveur. Nous voyons généralement cela sur les hébergeurs mutualisés. Ou peut-être que vous configurez votre propre serveur, auquel cas il se peut que certains des en-têtes ci-dessus ne soient pas encore ajoutés.

Et si tout se passe bien, et que vous n’avez pas de requêtes de tiers qui n’utilisent pas correctement l’en-tête, vous devriez voir une amélioration sur votre score avec des outils de test de vitesse de site web tels que Pingdom (comme vu ci-dessous).