Le problème apparaît lorsqu’un tableau affiche 70 % de réponses 304 alors que l’origine continue à recalculer chaque page. Le corps n’est pas transféré, mais l’application charge la base, assemble le document, calcule un hash puis découvre seulement à la fin que le validateur n’a pas changé. Le statut paraît économique alors que CPU, latence et dépendances restent presque identiques.
L’audit vérifie la promesse de bout en bout : qui émet le validateur, où la condition est évaluée, quel travail est réellement évité et comment Googlebot se comporte sur les cohortes concernées. Il relie les en-têtes HTTP aux traces CDN et applicatives, plutôt qu’à un simple compteur de statuts.
Le vrai enjeu est qu’une 304 ne devient une optimisation que si la décision intervient avant le coût qu’elle prétend supprimer. Paradoxalement, augmenter le taux de 304 peut dégrader l’origine si les validateurs deviennent plus précis mais exigent un rendu complet à chaque requête. Le bon indicateur est le travail épargné, pas la brièveté de la réponse.
L’accompagnement Tech SEO et performance web relie protocole HTTP, cache CDN, instrumentation et crawl. Il aide à conserver une fraîcheur fiable sans transformer chaque revalidation en calcul caché.
Distinguer corps économisé et calcul évité
Une réponse 304 indique que la représentation n’a pas besoin d’être retransmise au client pour la condition fournie. Elle économise donc les octets du corps sur ce tronçon. Elle ne dit rien, à elle seule, sur les requêtes SQL, appels API, rendu Twig ou sérialisation exécutés avant la comparaison.
Le coût est découpé en réseau client-CDN, réseau CDN-origine, traitement proxy, application et dépendances. Un CDN peut répondre sur son propre validateur sans toucher l’origine ; il peut aussi revalider systématiquement auprès d’elle. Deux réponses 304 identiques côté bot ont alors des coûts d’infrastructure très différents.
Le premier signal faible est un temps origine des 304 proche de celui des 200. Le deuxième est une hausse des connexions base ou API corrélée aux revalidations, malgré une baisse des octets sortants. Ces observations déclenchent une trace détaillée avant toute conclusion.
Comprendre ETag, dates et requêtes conditionnelles
Évaluer la condition au bon niveau
If-None-Match transporte un ou plusieurs ETag ; If-Modified-Since transporte une date issue de Last-Modified. Pour une requête GET ou HEAD, un validateur correspondant peut conduire à 304. ETag permet une identité plus précise ; la date reste limitée par sa résolution et la fiabilité de l’horloge.
Un ETag fort représente des octets identiques ; un ETag faible, explicitement préfixé W/, signale une équivalence suffisante pour certaines opérations de cache. Le choix doit correspondre au contenu. Inclure un nonce, une date de rendu ou un identifiant d’instance rend le validateur instable et force des 200 même lorsque la ressource métier n’a pas changé.
La condition doit pouvoir être évaluée depuis une version peu coûteuse : révision CMS, timestamp de dépendance, hash stocké ou manifeste de build. Calculer l’ETag en hachant le corps fraîchement rendu économise le transfert, mais rarement le calcul. Le contrat indique la source du validateur et ce qu’elle couvre.
Le contrat d’implémentation nomme entrées, sorties, responsabilités, dépendances et seuils de monitoring. L’instrumentation conserve la traçabilité de la révision ; la journalisation relie cache et origine ; le runbook décrit repli et rollback. Pour JavaScript, la CI et la QA testent HTML, hydratation, SSR, SSG, ISR et render sur les routes Next, Nuxt ou Remix.
Cartographier navigateur, CDN et origine
La carte décrit qui possède la réponse, sa durée de fraîcheur, le validateur transmis et la règle de revalidation. Le bot peut contacter le CDN ; le CDN peut servir un hit frais, répondre 304 sur une copie, ou envoyer une requête conditionnelle à l’origine. Les en-têtes Age, Via, statuts cache et traces permettent de distinguer ces chemins.
Les clés de cache incluent host, chemin, query string autorisée et variantes nécessaires. Une clé trop fine multiplie les objets à revalider ; une clé trop large mélange des contenus. Les cookies inutiles peuvent rendre la réponse privée et contourner le cache partagé, laissant l’application gérer toutes les conditions.
Le coût caché comprend les connexions et files d’attente. Une 304 de 200 octets peut attendre derrière un rendu lourd, occuper un worker et déclencher plusieurs appels. Le budget doit donc inclure temps de service, simultanéité et dépendances, pas uniquement bande passante.
Auditer la stabilité des validateurs
Comparer même version et vraie modification
Le test demande deux fois la même URL sans modification et attend le même ETag ou une date cohérente. Il modifie ensuite un champ visible critique et vérifie que le validateur change. Une dépendance non couverte produit une 304 incorrecte ; une donnée volatile non pertinente produit des 200 inutiles.
Les variantes sont testées séparément : langue, encodage, device ou négociation. Pour des représentations qui diffèrent par Content-Encoding, chaque forme — identity, gzip ou br — reçoit un ETag fort distinct et la réponse déclare Vary: Accept-Encoding. Une équivalence sémantique ne peut partager qu’un validateur faible préfixé W/ ; il ne convient ni aux comparaisons fortes ni aux requêtes de plage. CDN et origine doivent appliquer le même contrat.
Le troisième signal faible est une cardinalité d’ETag proche du nombre de requêtes pour une page rarement modifiée. Le quatrième est un Last-Modified égal à l’heure de chaque requête. Ces motifs révèlent un validateur lié au rendu, non à la version du contenu.
Mesurer octets, CPU, latence et cache
La baseline segmente 200, 304, hits CDN frais et revalidations origine. Pour chaque groupe, elle calcule requêtes, octets client, octets origine, temps CDN, temps application, CPU, requêtes de base, appels externes et taux d’erreur. Les mêmes gabarits et périodes sont comparés.
Le ratio 304 reste utile mais secondaire. Une économie réelle se lit dans la réduction d’octets et de travail par requête conditionnelle. Le tableau peut produire un coût moyen pondéré : temps CPU plus appels dépendants et bande passante, sans prétendre convertir chaque ressource en euros si les prix ne sont pas connus.
La queue longue compte autant que la moyenne. Un p50 rapide peut cacher des 304 qui attendent une API lente. Le p95, la simultanéité et la file de workers montrent si la revalidation protège l’origine pendant un pic de crawl.
Segmenter Googlebot sans optimiser pour un user-agent
Les logs vérifient Googlebot par DNS et conservent user-agent, URL, condition reçue, statut et version. La cohorte bot est comparée au trafic global pour comprendre la fréquence des revalidations. Le serveur ne doit pas renvoyer un comportement de cache artificiellement différent au robot.
Les pages sont segmentées par gabarit, fréquence de modification et valeur. Une page stable peut bénéficier de validateurs durables ; une page de stock très volatile exige une politique de fraîcheur différente. Une règle unique ferait soit trop de calcul, soit trop de contenu ancien.
L’objectif n’est pas de forcer Googlebot à envoyer une condition. Le site publie des validateurs corrects et mesure ce qui arrive. S’il reçoit surtout des 200, il inspecte stabilité des en-têtes, cache et versions avant d’imputer le comportement au robot.
Choisir revalidation, fraîcheur ou cache partagé
Une ressource stable peut avoir une fraîcheur longue et revalider rarement. Une page sensible conserve une fenêtre courte ou une invalidation événementielle. Une réponse personnalisée ne doit pas passer en cache public simplement pour améliorer un ratio. Sécurité et exactitude priment sur l’économie.
Le choix oppose parfois complexité et gain. Stocker une version métier permet une 304 très précoce, mais exige que toutes les dépendances mettent cette version à jour. Si ce contrat est fragile, un cache partagé court et une génération optimisée peuvent être plus sûrs qu’un ETag supposé parfait.
La décision est explicite : conserver la politique si coût et fraîcheur tiennent ; déplacer l’évaluation au CDN ou à un manifeste si l’origine travaille trop ; retirer un validateur incorrect ; ou différer l’optimisation si son mécanisme de version risque de servir un contenu périmé.
Arbitrer une charge entièrement simulée
Prenons un scénario entièrement simulé de 12 millions de requêtes mensuelles. Les 304 représentent 64 % des réponses Googlebot et 9 % du trafic total. Pourtant, leurs traces fictives montrent 78 ms de CPU médian contre 84 ms pour les 200, car l’application rend la page avant de calculer l’ETag.
Exemple concret simulé. L’équipe remplace le hash du corps par une révision de contenu stockée, évaluée au proxy applicatif. Sur un canari de deux gabarits, le CPU médian des 304 descend fictivement à 7 ms, les requêtes SQL de 11 à 0 et les octets restent faibles. Une modification réelle change bien la révision et renvoie 200 avec le nouveau corps.
Décision simulée. L’extension exige 95 % des conditions évaluées avant le contrôleur, aucune 304 sur une révision modifiée, un p95 inférieur à 25 ms et une baisse d’au moins 50 % du CPU de la cohorte. Ces seuils illustratifs ne sont ni des normes HTTP ni une promesse de performance.
La contre-intuition est nette : le taux de 304 ne change presque pas, mais l’économie devient réelle. L’amélioration vit dans le lieu de décision et dans la version, pas dans une hausse cosmétique du statut.
Recetter 200, 304 et modification réelle
La recette effectue un GET initial, conserve ETag et Last-Modified, puis envoie les conditions séparément et ensemble. Lors du test combiné, If-None-Match prime et If-Modified-Since doit être ignoré. Elle attend 304 sans corps quand la version est identique. Après modification, elle attend 200, nouveau validateur et contenu actualisé. Les dates futures, ETag faibles préfixés W/ et validateurs inconnus complètent la matrice.
Les tests traversent le CDN puis contournent ce dernier de façon autorisée pour isoler l’origine. Ils vérifient les en-têtes à chaque couche, la clé, Age, Vary et les traces. Un cache chaud et un cache froid sont distingués.
Le test de charge mélange hits frais, conditions valides et modifications. Il mesure CPU, dépendances, files et erreurs. Le rollback rétablit l’ancien validateur sans réutiliser des objets incompatibles ; une purge ciblée est préparée si le format d’ETag change.
La recette ajoute une cohorte Googlebot et une cohorte témoin sans traitement différencié. Elle compare crawl, indexation, canonicale, TTFB, revalidation et invalidation pour vérifier que l’économie ne modifie pas l’identité publique. Si la révision servie diverge, alors le canari s’arrête plutôt que de prolonger un cache périmé.
Détecter les 304 coûteuses dans le temps
Le monitoring suit ratio 304, coût moyen, p95, accès base, revalidations origine et invalidations. Il segmente par gabarit et couche. Une alerte s’ouvre si le coût des 304 rejoint celui des 200 ou si la part de conditions évaluées tardivement augmente après une release.
Une variation du validateur sans changement métier révèle une dépendance volatile. Une chute soudaine des 304 peut signaler un ETag instable, une perte d’en-tête au CDN ou une clé modifiée. Chaque alerte inclut exemple de trace, version, host et propriétaire.
Le rapport compare aussi fraîcheur et erreurs. Une économie de CPU obtenue en servant des versions anciennes est refusée. Le garde-fou lit révision attendue, révision servie et temps depuis modification sur un échantillon synthétique.
Pour qui et dans quels cas adapter le contrôle
L’audit complet convient aux sites à fort crawl, médias, catalogues et applications dont le rendu sollicite beaucoup l’origine. Il devient prioritaire lorsque les 304 représentent un volume important mais que la charge ne baisse pas, ou lors d’une migration CDN.
Pour un petit site statique, quelques requêtes curl et l’observation des journaux suffisent. La version provient souvent du build et la 304 est déjà décidée par le serveur. Construire un pipeline de traces serait disproportionné.
Le développeur possède la version, le SRE instrumente les couches, SEO choisit les cohortes bot et le responsable produit fixe la tolérance de fraîcheur. La livraison est signée seulement quand performance et exactitude restent conformes.
Erreurs fréquentes : trois fausses économies HTTP
Hasher le HTML après rendu
Cette méthode produit un validateur exact mais intervient trop tard pour économiser le calcul. Elle reste utile pour les octets, mais ne doit pas être présentée comme une protection d’origine. Une version amont est préférable si son invalidation est fiable.
Si le hash exige toutes les requêtes SQL et le render, alors le 304 protège seulement le réseau. Dans ce cas, le validateur est déplacé vers une révision amont ; en revanche, l’ancien mécanisme peut rester temporairement comme contrôle de cohérence durant le canari.
Forcer un Last-Modified artificiel
Une date figée peut produire des 304 sur un contenu changé ; une date à chaque requête produit des 200 permanents. L’horodatage doit représenter une modification réelle des dépendances visibles, avec une résolution connue.
La date provient plutôt d’un événement de publication fiable que de l’horloge du worker. Si plusieurs dépendances modifient la page, alors leur contrat alimente une version commune ; une source incomplète est refusée tant que la fraîcheur ne peut pas être éprouvée.
Mesurer seulement les octets client
Le CDN peut économiser le corps tout en sollicitant l’origine. Sans traces, CPU et appels, le coût est déplacé plutôt que supprimé. Le bilan sépare chaque tronçon et chaque couche de décision.
Le seuil de réussite associe octets, CPU, p95 et accès aux dépendances. Si la bande passante baisse mais que la file de workers s’allonge, alors l’extension est à différer ; la mesure privilégie la capacité réelle plutôt qu’un ratio de statuts flatteur.
Plan d’action : prouver le gain en dix jours
Jours 1 à 4 : cartographier et baseliner
Le premier jour sélectionne quatre gabarits selon fréquence de modification et coût. Le deuxième capture en-têtes et traces pour 200, hits frais, 304 CDN et 304 origine. Le troisième documente la source de chaque ETag ou Last-Modified, les dimensions Vary et la clé de cache.
Le quatrième calcule requêtes, octets, temps, CPU, SQL, appels externes, cache hit et erreurs par cohorte. Les bots vérifiés sont segmentés sans modifier leur réponse. L’équipe identifie le moment exact où la condition est évaluée et chiffre le travail déjà exécuté.
Jours 5 à 10 : corriger, éprouver et étendre
Le cinquième choisit une version peu coûteuse pour un gabarit canari. Le sixième aligne origine et CDN, puis prépare la purge ciblée et le retour arrière. Le septième exécute la matrice : version identique, modification, variantes, ETag faible, date et cache froid.
Le huitième lance une charge mixte et vérifie la fraîcheur. Le neuvième ouvre le canari en production avec seuils de CPU, latence, erreurs et révision. Le dixième compare la même cohorte et décide : étendre si le travail baisse sans 304 incorrecte ; corriger si une dépendance échappe à la version ; revenir en arrière si la fraîcheur diverge ; différer si le coût de gouvernance dépasse le gain.
- D’abord, tracer le lieu où la condition est réellement évaluée.
- Ensuite, versionner depuis les dépendances visibles, avant le rendu coûteux.
- Puis, éprouver réponse inchangée et modification réelle sur chaque couche.
- Enfin, étendre seulement si coût et fraîcheur tiennent ensemble.
- Conserver les traces du 200 initial, du 304 stable et de la modification réelle.
- Réviser les seuils par gabarit lorsque le coût du rendu ou la fréquence de mise à jour change.
Relier cache, TTFB et logs Googlebot
Auditer le backend et le CDN
L’audit TTFB, cache et CDN aide à replacer la revalidation dans la file, le calcul applicatif et la capacité d’origine.
Cette approche sépare le temps vu par le client du temps consommé derrière le proxy. Elle révèle notamment les 304 rapides au CDN qui déclenchent malgré tout une condition lente, une requête applicative ou un accès inutile à la base.
Analyser les robots dans les logs
La méthode d’analyse des bots Google dans les logs serveur complète les cohortes et la validation d’identité.
Les segments obtenus montrent quelles familles reçoivent des conditions, lesquelles reviennent en 200 et où l’origine est touchée. Ils évitent d’optimiser un user-agent isolé en donnant la même sémantique HTTP à tous les clients.
Consulter les références officielles
La RFC 9110 définit les requêtes conditionnelles, ETag, Last-Modified et le statut 304. La RFC 9111 précise le fonctionnement des caches HTTP et de la revalidation.
Google décrit la vérification des requêtes de ses robots par DNS inverse puis direct ou à partir des plages IP publiées.
Ces textes décrivent la sémantique protocolaire. Ils ne garantissent aucune économie applicative : seule l’instrumentation de la chaîne prouve le travail réellement évité.
Conclusion : mesurer le travail, pas le statut
Une 304 économise le corps de la représentation, mais pas automatiquement le calcul qui précède la décision. L’endroit où le validateur est évalué détermine la valeur réelle.
Une version stable et peu coûteuse permet de répondre avant le rendu. Les traces CDN et application séparent octets, CPU, dépendances et file d’attente.
La recette protège la fraîcheur : une modification réelle doit produire un nouveau validateur et un 200. Le canari refuse tout gain obtenu en servant une ancienne révision.
Pour auditer validateurs, cache partagé et coût origine, l’accompagnement Tech SEO et performance web de Dawap transforme la revalidation HTTP en économie démontrable.
