304 Not Modified : pourquoi c'est un succès, pas une erreur

Comment survient un 304

Un 304 est la seconde moitié d'une conversation en deux temps. À la première requête, le serveur renvoie la ressource avec un validateur : un ETag, qui est un identifiant opaque pour cette version exacte, et souvent une date Last-Modified. Le client stocke la réponse avec ces validateurs.

Plus tard, quand la copie en cache a besoin d'être revalidée, le client répète la requête et inclut ce qu'il a :

• If-None-Match: "abc123" porte l'ETag stocké. C'est le validateur préféré car il est exact.
• If-Modified-Since: Wed, 03 Sep 2026 10:00:00 GMT porte la date stockée, utilisée quand il n'y a pas d'ETag.

Si la ressource n'a pas changé, le serveur répond 304 Not Modified avec des en-têtes seulement et aucun corps, et le client affiche sa copie en cache. Si elle a changé, le serveur répond 200 avec le nouveau contenu et de nouveaux validateurs. Les deux issues sont un comportement correct.

Pourquoi un 304 est une bonne nouvelle, pas une erreur

Les gens voient un 304 dans le panneau réseau d'un navigateur ou un analyseur de journaux, remarquent que ce n'est pas un 200, et supposent que quelque chose a échoué. Rien n'a échoué. Un 304 est la réponse utile la moins coûteuse du web : aucun corps de réponse ne traverse le réseau, donc le transfert fait quelques centaines d'octets au lieu de l'actif complet, et le serveur évite en général de régénérer la ressource, ce qui coûte moins de CPU qu'un 200. La page s'affiche plus vite car le navigateur réutilise des octets qu'il a déjà. Les robots d'exploration en profitent aussi, puisqu'un ETag stable qui produit des 304 laisse un moteur de recherche dépenser son budget d'exploration sur les pages qui ont changé.

Une forte proportion de 304 sur les ressources statiques est le signe que la mise en cache est bien configurée. La seule chose à surveiller est de savoir si vous avez même besoin de l'aller-retour de revalidation : pour des ressources versionnées ou à empreinte, un long Cache-Control: max-age avec immutable évite même le 304, car le navigateur ne demande pas.

Quand un 304 est un problème

• Une page obsolète qui ne se rafraîchit pas. Si votre HTML est servi avec un validateur qui ne change jamais alors que le contenu change, les navigateurs continuent de recevoir des 304 et les utilisateurs continuent de voir l'ancienne page. C'est le bug classique « j'ai déployé mais personne ne le voit ».
• Un 304 sans copie en cache correspondante. Si un client envoie une requête conditionnelle sans en avoir de raison, ou si un proxy retire le corps d'un 200, le client se retrouve sans rien à afficher et la page apparaît vide.
• Des ETags faibles ou instables derrière un répartiteur de charge. Quand plusieurs serveurs backend génèrent des ETags différents pour un contenu identique, chaque revalidation échoue et vous obtenez des 200 complets là où des 304 étaient attendus. Le trafic augmente sans raison.
• La compression qui change le validateur. Si l'ETag diffère entre les variantes compressée et non compressée sans un Vary: Accept-Encoding correct, les caches peuvent servir la mauvaise chose.

Comment tester les requêtes conditionnelles

1. Récupérez la ressource et lisez ses validateurs :

   curl -sI https://example.com/style.css | grep -Ei "^(HTTP|etag|last-modified|cache-control)"

2. Répétez la requête avec l'ETag que vous avez obtenu et confirmez que le serveur répond 304 :

   curl -sI -H 'If-None-Match: "abc123"' https://example.com/style.css | head -n 1

   Substituez la valeur exacte de l'ETag, guillemets compris. Un 200 ici signifie que la revalidation ne fonctionne pas.
3. Si vous obtenez 200 alors que vous attendiez 304, vérifiez si un proxy ou un CDN retire If-None-Match, et si vos serveurs backend s'accordent sur l'ETag pour le même fichier.
4. Si vous obtenez une page obsolète, faites en sorte que le validateur change quand le contenu change. Les noms de fichiers à empreinte sont la correction la plus fiable ; sinon, dérivez l'ETag du contenu lui-même.
5. Gardez le HTML sur une durée de fraîcheur courte et laissez les ressources porter la longue. Un HTML mis en cache pendant une journée est ce qui rend un déploiement invisible.

Pourquoi les vérifications d'uptime ne voient jamais de 304

Une vérification d'uptime demande une page comme un visiteur de première fois, sans If-None-Match ni If-Modified-Since, donc le serveur n'a rien à comparer et répond toujours 200. C'est le bon comportement par défaut pour la disponibilité. Cela signifie aussi que les régressions de mise en cache n'apparaissent pas du tout dans les données d'uptime : un site peut servir une page obsolète à tout le monde pendant que chaque vérification reste au vert. Vérifiez le contenu de la page en plus du statut, et une page qui a cessé de se mettre à jour devient visible comme une incohérence de contenu. HostTracker propose 13 types de moniteurs et surveille des sites web depuis 2004. Testez les en-têtes et le statut avec l' outil de vérification HTTP, et voyez ce que prouve vraiment un 200 OK et le guide complet de la famille 3xx.