{"id":31069,"date":"2019-09-09T04:24:55","date_gmt":"2019-09-09T11:24:55","guid":{"rendered":"https:\/\/kinsta.com\/?post_type=knowledgebase&p=10615"},"modified":"2025-10-01T20:51:46","modified_gmt":"2025-10-01T19:51:46","slug":"specify-a-cache-validator","status":"publish","type":"post","link":"https:\/\/kinsta.com\/fr\/blog\/specify-a-cache-validator\/","title":{"rendered":"Comment r\u00e9parer l’avertissement \u00ab\u00a0Specify a cache validator\u00a0\u00bb ?"},"content":{"rendered":"

Vous voyez l’avertissement \u00ab\u00a0Specify a cache validator\u00a0\u00bb dans Pingdom<\/a>, GTmetrix<\/a>, ou Google PageSpeed Insights<\/a> sur votre site WordPress ? Ceci est d\u00fb \u00e0 l’absence d’en-t\u00eates de mise en cache HTTP qui doivent \u00eatre inclus dans chaque r\u00e9ponse du serveur d’origine, car ils valident et d\u00e9finissent la longueur du cache<\/strong>. Si les en-t\u00eates ne sont pas trouv\u00e9s, une nouvelle requ\u00eate pour la ressource sera g\u00e9n\u00e9r\u00e9e \u00e0 chaque fois, ce qui augmente la charge sur votre serveur. L’utilisation d’en-t\u00eates de mise en cache garantit que les requ\u00eates ult\u00e9rieures n’ont pas \u00e0 \u00eatre charg\u00e9es \u00e0 partir du serveur, ce qui permet d’\u00e9conomiser de la bande passante et d’am\u00e9liorer les performances de l’utilisateur.<\/p>\n

\"Avertissement
Avertissement Specify a cache validator<\/figcaption><\/figure>\n

L’avertissement de Pingdom dit :<\/p>\n

Il manque un validateur de cache aux ressources suivantes. Les ressources qui ne sp\u00e9cifient pas de validateur de cache ne peuvent pas \u00eatre actualis\u00e9es efficacement. Sp\u00e9cifiez un en-t\u00eate Last-Modified ou ETag pour activer la validation du cache pour les ressources suivantes.<\/p><\/blockquote>\n

Suivez les \u00e9tapes ci-dessous pour corriger l’avertissement \u00ab\u00a0Specify a cache validator\u00a0\u00bb.<\/p>\n

Correction de l’avertissement \u00ab\u00a0Specify a cache validator\u00a0\u00bb.<\/h2>\n

La premi\u00e8re chose qu’il est important de noter \u00e0 propos de cet avertissement est que vous ne pouvez le corriger que pour les requ\u00eates qui sont sur votre serveur<\/strong>. Si vous avez des requ\u00eates de tierces parties sur lesquelles vous voyez cela, il n’y a rien que vous puissiez faire car vous n’avez pas de contr\u00f4le sur leurs serveurs web. N’h\u00e9sitez pas \u00e0 partager cet article avec eux. Et rappelez-vous qu’avec Pingdom, vous devrez peut-\u00eatre faire le test plusieurs fois. Il se peut que l’avertissement apparaisse la premi\u00e8re fois et disparaisse la deuxi\u00e8me fois. Lorsque vous ex\u00e9cutez l’outil pour la premi\u00e8re fois, il amorce le cache des ressources \u00e0 partir du serveur.<\/p>\n

Il existe quatre types diff\u00e9rents d’en-t\u00eates qui peuvent \u00eatre utilis\u00e9s de diff\u00e9rentes mani\u00e8res pour corriger cet avertissement. C’est l\u00e0 que \u00e7a peut devenir un peu confus, mais nous allons essayer de l’expliquer aussi facilement que possible.<\/p>\n

En-t\u00eates qui valident le cache<\/h3>\n

Les deux premiers en-t\u00eates sont les Last-Modified<\/strong> et ETag<\/strong>. Ces en-t\u00eates aident le navigateur \u00e0 d\u00e9terminer si le fichier a chang\u00e9<\/strong> depuis la derni\u00e8re fois qu’il a \u00e9t\u00e9 demand\u00e9. Ou plut\u00f4t, ils valident le cache.<\/p>\n

1. Last-Modified<\/h4>\n

L\u2019en-t\u00eate Last-Modified<\/strong> est g\u00e9n\u00e9ralement envoy\u00e9 automatiquement depuis le serveur. C’est un en-t\u00eate que vous n’aurez g\u00e9n\u00e9ralement pas besoin d’ajouter manuellement<\/strong>. Il est envoy\u00e9 pour voir si le fichier dans le cache du navigateur a \u00e9t\u00e9 modifi\u00e9 depuis la derni\u00e8re fois qu’il a \u00e9t\u00e9 demand\u00e9. Vous pouvez consulter la requ\u00eate d’en-t\u00eate dans Pingdom ou utiliser Chrome DevTools pour voir la valeur de l\u2019en-t\u00eate Last-Modified.<\/p>\n

\"En-t\u00eate
En-t\u00eate Last-Modified<\/figcaption><\/figure>\n

2. ETag<\/h4>\n

L’en-t\u00eate ETag<\/strong> est \u00e9galement tr\u00e8s similaire \u00e0 l\u2019en-t\u00eate Last-Modified. Il sert \u00e9galement \u00e0 valider le cache d’un fichier. Si vous utilisez Apache 2.4 ou sup\u00e9rieur, l’en-t\u00eate ETag est d\u00e9j\u00e0 automatiquement ajout\u00e9 en utilisant la directive FileETag<\/a>. Et en ce qui concerne NGINX, depuis 2016, l’en-t\u00eate ETag est activ\u00e9 par d\u00e9faut.<\/p>\n

\"En-t\u00eate
En-t\u00eate ETag<\/figcaption><\/figure>\n

Vous pouvez activer manuellement l’en-t\u00eate ETag<\/a> dans NGINX en utilisant le code suivant.<\/p>\n

etag on<\/code><\/pre>\n
En-t\u00eates qui d\u00e9terminent la longueur du cache<\/h3>\n
Les deux en-t\u00eates suivants sont Cache-Control<\/strong> et Expires<\/strong>. Ces en-t\u00eates aident \u00e0 d\u00e9terminer combien de temps le fichier doit \u00eatre conserv\u00e9 en cache<\/strong> avant qu’il ne r\u00e9cup\u00e8re 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\u00eate qui valide \u00e0 la fois le cache, ainsi qu’un qui d\u00e9termine la longueur du cache.<\/p>\n
3. Cache-Control<\/h4>\n
Cache-Control<\/strong> est un en-t\u00eate compos\u00e9 de diff\u00e9rentes directives qui vous permettent de d\u00e9finir la longueur du cache. Quelques-unes des directives les plus courantes sont les suivantes :<\/p>\n