Early Hints : un cache désactivé peut fausser votre test

Le serveur envoie bien une réponse 103 Early Hints, mais la feuille de style ne démarre pas avant le HTML dans votre capture réseau. L’équipe soupçonne le CDN, ajoute un autre preload puis conclut que l’optimisation ne fonctionne pas. Le risque est de financer une modification inutile du CDN. Une option de son protocole peut pourtant neutraliser le mécanisme qu’elle cherche à observer : « Disable cache » dans Chrome DevTools.

En pratique, vider un cache avant une visite et empêcher son utilisation pendant toute la visite sont deux expériences différentes. Pour qualifier un préchargement Early Hints, il faut suivre le signal reçu, la requête anticipée, sa réutilisation par le document et le rendu final. La présence du statut 103 ne prouve aucune de ces étapes suivantes.

Ce diagnostic appartient au SEO technique des pages d’acquisition. Il complète une démarche de performance et Core Web Vitals lorsque le HTML attend le serveur alors que certaines ressources critiques sont déjà prévisibles. Une meilleure capture permet d’arbitrer l’investissement ; elle ne garantit ni classement ni hausse des conversions.

Les notes Chrome DevTools publiées le 20 octobre 2026, sous le titre « November 2026 », annoncent un avertissement pour ce cas. Elles améliorent le diagnostic d’un comportement déjà documenté, sans annoncer la naissance des Early Hints. Les sources ont été vérifiées le 24 octobre. Les calculs ci-dessous utilisent uniquement des observations fictives, accompagnées d’un programme Python reproductible.

Pour qui : prouver une optimisation avant de généraliser les hints

Partir d’une page d’entrée et d’une attente identifiable

Le bon candidat est une page d’acquisition dont le document final demande un travail serveur et dont une ressource nécessaire peut être anticipée. Une catégorie de catalogue peut, par exemple, attendre son assortiment tout en utilisant une feuille de style commune connue. Le problème à résoudre est l’attente avant découverte de cette feuille, pas l’existence abstraite d’un score Lighthouse perfectible.

Commencez par une trace du parcours actuel. Si le document arrive presque immédiatement, le temps disponible pour anticiper une requête peut être trop faible. Si le retard principal vient d’un script d’hydratation qui masque le contenu, télécharger le CSS plus tôt ne traite pas directement cette cause. L’arbitrage doit donc nommer la dépendance que l’on espère déplacer avant de modifier le serveur ou le CDN.

Attribuer la configuration et la preuve à des responsables distincts

L’équipe plateforme connaît l’émission des réponses intermédiaires et les règles du CDN. Le frontend connaît les ressources réellement utilisées par chaque version. La QA décrit le navigateur, le profil réseau et l’état des caches. Le responsable performance relie ces observations au LCP. Une capture isolée envoyée sans ces conditions laisse chacun diagnostiquer une expérience différente.

Le contrat de recette doit conserver cette répartition. Son entrée comprend une page, une version et une hypothèse de ressource critique ; sa sortie comprend une chronologie, une comparaison recevable et une décision. Le seuil d’arrêt vise les ressources inutiles ou les régressions constatées. La responsabilité du repli doit être attribuée avant d’étendre la configuration à tous les gabarits publics.

Ce que précise l’avertissement DevTools d’octobre

Une aide au diagnostic, pas une nouvelle règle de classement

Les notes officielles DevTools du 20 octobre décrivent un avertissement dans les en-têtes Early Hints lorsque la réponse contient des liens preload alors que Disable cache est actif. Le message explique pourquoi Chrome ignore ces préchargements. Il faut relever la version réellement utilisée : une interface plus ancienne peut ne pas présenter cet avertissement de la même façon.

Paradoxalement, rendre la mesure plus sévère en supprimant toute utilisation du cache peut retirer précisément la possibilité que l’on voulait tester. L’absence de requête anticipée ne démontre alors pas une panne du serveur. Elle décrit d’abord l’expérience choisie dans l’outil. Cette distinction évite une correction inutile de la configuration publique pour satisfaire une recette qui exclut son mécanisme.

Écrire l’état de l’option dans le rapport de test

La référence du panneau Network présente séparément la désactivation du cache et son effacement manuel. Ces actions ne doivent pas être regroupées sous la simple étiquette « test froid ». Le rapport doit indiquer ce qui a été effacé, à quel moment et si le cache restait utilisable pendant le chargement observé.

Un passage avec Disable cache peut rester utile à d’autres diagnostics. Conservez-le, mais donnez-lui son propre périmètre. Ne le comparez pas silencieusement à un passage où le navigateur peut conserver une ressource préchargée. La suppression d’une observation gênante après examen du résultat n’est pas davantage acceptable : les critères de comparaison doivent être définis avant de choisir le chiffre à présenter.

Le 103 annonce des ressources avant la réponse finale

Lire deux réponses sans prendre la première pour le document

La RFC 8297 consacrée aux Early Hints définit une réponse informative précédant la réponse finale. Elle permet de transmettre des indications pendant sa préparation. Elle n’oblige pas le client à les exploiter et ne remplace pas le statut, les en-têtes et le corps de la réponse finale. Une capture contenant 103 doit donc encore montrer ce qui arrive ensuite. Un TTFB isolé ne suffit pas : conservez les repères de la réponse intermédiaire et de la réponse finale, avec la définition utilisée par l’outil.

103 Early Hints
Link: </assets/catalog.v7.css>; rel=preload; as=style

200 OK
Content-Type: text/html

<link rel="stylesheet" href="/assets/catalog.v7.css">

Cette transcription simplifiée décrit un échange, pas une configuration serveur à copier. Elle omet les autres en-têtes et la trame du protocole. Le document conserve un lien de feuille de style normal : il doit fonctionner si les indications anticipées ne sont pas utilisées. Envoyer seulement un hint ne constitue pas une manière de déclarer toute la présentation de la page.

Choisir une ressource connue et réellement réutilisable

La documentation Chrome sur les chargements anticipés avec Early Hints décrit le recours au cache HTTP pour retrouver les ressources préchargées. Elle demande de décocher Disable cache et d’utiliser un certificat HTTPS de confiance pour les essais concernés. Elle précise aussi les limites du préchargement et les différences de prise en charge entre navigateurs.

Le pilote doit donc suivre le comportement effectif du navigateur retenu, sans transposer automatiquement une réussite Chrome à tous les visiteurs. Notre exemple utilise une feuille CSS déterminée et des conditions h2 qualifiées. Il ne teste pas une image responsive, une navigation après redirection ou une ressource personnalisée. Ces situations demandent leurs propres vérifications avant d’étendre le même réglage.

Cache vide, cache désactivé et visite chaude : trois situations

Préparer un état initial sans supprimer le mécanisme pendant la visite

Dans notre protocole, le navigateur commence sans la ressource du catalogue, mais son cache HTTP reste utilisable. Une réponse anticipée peut alors provoquer un transfert, puis le document peut retrouver la ressource obtenue pendant cette même navigation. L’étiquette de réutilisation ne prouve donc pas, à elle seule, que l’utilisateur avait déjà visité la page auparavant.

Il faut conserver la chronologie complète pour expliquer cette situation. À quel instant le hint est-il arrivé ? Quelle requête a suivi ? Le document demande-t-il la même URL ? Le réseau montre-t-il un second transfert ? Une lecture limitée à la dernière ligne « cache » peut effacer le premier téléchargement de l’analyse et donner l’impression trompeuse d’une visite déjà chaude.

Ne pas refroidir toutes les couches par habitude

Un navigateur vide peut atteindre un objet déjà présent au CDN. Il ne représente pas une purge du CDN, ni une base applicative froide, ni une connexion réseau nécessairement nouvelle. Le rapport doit donc conserver l’état de chaque couche utile à l’hypothèse. Purger l’infrastructure entre deux passages change l’expérience et peut introduire une attente qui n’existait pas sur le trafic ordinaire.

Le scénario de retour garde aussi son intérêt : les ressources peuvent déjà être présentes et le bénéfice marginal d’un hint devenir faible. Il faut mesurer ce parcours séparément. Une optimisation destinée aux premières arrivées ne devrait pas être jugée uniquement sur une visite chaude, ni imposer un coût supplémentaire aux visiteurs récurrents pour rendre la comparaison plus spectaculaire.

Suivre quatre preuves dans la même navigation

Du signal reçu à la feuille effectivement utilisée

La première preuve est la réception de l’indication sur le document étudié ; la deuxième est le démarrage anticipé de la requête attendue. Ces observations doivent rester liées à la même navigation et à la même version. Le fait que les logs d’un proxy annoncent l’émission d’un 103 ne dit pas encore ce qui a atteint le navigateur ou ce que celui-ci a choisi d’en faire.

La troisième preuve est la consommation de la bonne ressource. Comparez l’URL annoncée et celle référencée par le document final, avec leurs versions et leurs conditions de requête. Si l’HTML utilise catalog.v7.css alors que le hint désigne catalog.v6.css, la présence d’un transfert précoce peut seulement révéler des octets inutiles. Elle n’est pas un succès à conserver dans le tableau de performance.

Du transfert utile au contenu effectivement rendu

La quatrième preuve porte sur le rendu observé. Le diagnostic du LCP présenté par web.dev rappelle que les étapes de chargement et d’affichage doivent être examinées ensemble. La ressource peut arriver plus tôt tandis qu’un autre travail reste bloquant. Une avance de téléchargement ne doit donc pas être recopiée comme une économie identique sur le LCP.

Conservez l’élément LCP, les repères de la trace et les autres ressources critiques. Un changement de héros vers un titre ne se résume pas à deux nombres comparables. Sur un vrai parcours, recherchez la cause du délai restant avec les éléments disponibles : CSS, travail JavaScript, visibilité du composant ou autre dépendance. Nos observations fictives permettent de calculer l’écart ; elles ne permettent pas de déduire une cause de rendu absente des données.

Exemple concret : 670 ms d’avance réseau, 220 ms de gain LCP

Fixer un témoin avant de calculer le résultat

Une catégorie fictive utilise un CSS de 44 Kio et une réponse finale à 800 ms. Le témoin A ne reçoit pas de hint. Sa requête CSS commence à 820 ms, se termine à 1 040 ms et son LCP vaut 1 500 ms. Le passage B reçoit un 103 à 120 ms ; le CSS démarre à 150 ms et se termine à 370 ms. Le document le réutilise et le LCP est fixé à 1 280 ms.

Le corrigé donne 820 − 150 = 670 ms d’avance au démarrage, mais 1 500 − 1 280 = 220 ms de gain sur le LCP. Ce dernier écart représente environ 14,67 % du LCP témoin. Les données ont été choisies pour montrer cette différence ; elles ne constituent pas une mesure Chrome, un benchmark du site ou une estimation de ce qu’un client gagnerait.

Écarter une comparaison invalide sans cacher un résultat décevant

Le passage C décrit un test avec Disable cache et aucune requête anticipée. Il ne respecte pas les conditions retenues pour comparer A et B. Le passage D démarre avec un cache chaud : son avantage apparent de 400 ms sur A ne peut pas être attribué aux Early Hints. Le programme refuse ces rapprochements en nommant la condition différente, plutôt qu’en leur donnant un gain global.

Une variante F conserve au contraire les conditions de B et son CSS précoce, mais fixe le LCP à 1 500 ms. La comparaison est recevable et son gain vaut zéro. Une autre variante porte le LCP à 1 580 ms : elle donne une régression de 80 ms, également conservée. Le protocole ne doit pas éliminer les résultats négatifs au prétexte qu’ils ne correspondent pas au bénéfice attendu.

Le mauvais hash peut transformer l’anticipation en gaspillage

Un transfert précoce qui ne sert pas le document final

Dans le passage E, le hint annonce l’ancienne feuille v6. Elle occupe 44 Kio de transfert entre 150 et 370 ms. Le document final demande toujours v7, qui arrive entre 820 et 1 040 ms, comme dans le témoin. Le LCP reste fixé à 1 500 ms. L’exercice calcule donc zéro gain et 45 056 octets transférés supplémentaires, soit 44 × 1 024.

Cette observation n’est pas rejetée comme une différence de population : le document, le réseau et les autres conditions prévues restent identiques. Elle est un résultat défavorable de la configuration testée. L’identité du fichier est une pièce de la preuve, et non un détail technique que l’on peut supprimer du rapport pour ne conserver que l’heure du premier téléchargement.

Faire évoluer les hints avec la version du frontend

La règle d’exploitation doit relier le manifeste des assets et la configuration qui annonce leur chargement. Si la réponse intermédiaire est produite par une autre couche que le HTML, la recette vérifie leur correspondance après une publication et après un retour arrière. L’invalidation du cache de l’un ne prouve pas automatiquement que l’autre utilise désormais la même version.

Le coût de maintien fait partie de la décision. Un hint fragile, inutile sur la plupart des entrées et difficile à retirer peut coûter plus qu’il n’apporte. Pour une hypothèse de vingt passages de recette demandant chacun six minutes de préparation et d’analyse, comptez déjà 120 minutes. Ce calcul illustratif n’est ni un devis ni une économie observée ; il rappelle simplement que la validation a un travail propre.

Reproduire 47 contrôles sur des observations fictives

Comparer les conditions avant d’agréger les écarts

Le programme Python de comparaison des essais Early Hints fonctionne avec la bibliothèque standard. Il contient ses observations inventées et un corrigé indépendant. Il ne lance aucun navigateur, n’émet aucune réponse HTTP, ne lit aucun HAR et n’implémente pas le cache de Chrome. Son objet est de vérifier ce que l’on accepte de comparer et comment on calcule les différences.

python3 early_hints_mesures.py
# Résultat attendu : status PASS, checks 47
# Trois paires : gain médian fictif de 220 ms

Trois paires prédéfinies ont des LCP témoins de 1 500, 1 520 et 1 480 ms ; les passages activés valent 1 280, 1 300 et 1 260 ms. Chaque différence vaut 220 ms. Les six permutations de l’ordre des paires donnent le même résultat. Le programme refuse une paire incomplète, un passage répété et un regroupement contenant des conditions initiales différentes.

Garder les inconnues et les résultats négatifs visibles

Les contrôles couvrent aussi des changements de navigateur, de réseau, de CPU, de viewport, de version, de CDN, de service worker et d’élément LCP. Une condition absente, un booléen remplacé par une chaîne, des octets négatifs ou une chronologie incohérente déclenchent un refus. Les identifiants de paire ne sont pas déduits du tri des résultats : ils appartiennent à la préparation de l’expérience.

Dans une variante des trois paires, le dernier gain devient −80 ms. La médiane reste 220 ms, mais le minimum révèle la régression. Cet exemple montre pourquoi une valeur centrale seule ne suffit pas. Trois paires fabriquées ne constituent évidemment pas un échantillon statistique du trafic. Le programme vérifie une convention de calcul ; le volume nécessaire à une décision réelle dépend de la variabilité et du protocole retenu.

Décider sur le terrain sans transformer un laboratoire en promesse SEO

Relier la population réelle à l’hypothèse testée

Les différences entre laboratoire et données terrain expliquent pourquoi une mesure contrôlée ne représente pas automatiquement les visiteurs. Appareils, réseaux et parcours varient. Un canari doit conserver la version exposée et une population comparable, puis vérifier si le mécanisme ciblé améliore effectivement l’expérience concernée sans déplacer le coût vers d’autres ressources.

Le RUM peut suivre le gabarit, la version et le type de navigation avec une cardinalité maîtrisée. CrUX apporte un autre périmètre de mesure, à interpréter comme tel. Le seuil usuel de 2,5 secondes de LCP au 75e percentile n’est pas la médiane de trois essais locaux. Le rapport doit nommer son indicateur et sa population avant d’afficher un statut favorable.

Préserver les autres exigences de la page publique

Un chargement anticipé ne corrige ni une mauvaise canonical, ni un contenu absent du rendu SSR, ni une page exclue de l’indexation. Le contrôle SEO conserve donc les réponses publiques, le HTML utile et les liens de navigation. Il vérifie aussi que le fallback normal fonctionne quand un navigateur n’exploite pas le hint. La performance complète ces exigences ; elle ne les remplace pas.

La recette suit également les erreurs de ressources, les octets précoces et les autres Core Web Vitals pertinents, notamment CLS et INP. Un gain de LCP obtenu en surchargeant le réseau ou en dégradant les interactions peut déplacer le problème. Les changements de trafic et de conversion restent à examiner avec leur contexte ; aucune règle ne permet de convertir nos 220 ms fictives en un nombre de positions ou de demandes commerciales.

Plan d’action : qualifier le protocole avant d’étendre la configuration

Préparer un témoin et une activation qui ne changent qu’un mécanisme

Choisissez une page d’entrée dont le HTML final et la feuille critique sont connus. Notez la version, le navigateur, le viewport, le réseau, le CPU, le service worker et les états du CDN et du cache navigateur. Définissez la métrique principale, les observations nécessaires et les motifs de refus avant d’exécuter les passages. Si une de ces conditions n’est pas observable, marquez-la inconnue et réduisez la portée de la conclusion au lieu de lui attribuer une valeur favorable.

Préparez le cache initial selon la population choisie tout en le laissant utilisable pour le scénario Early Hints. Conservez un témoin sans activation et une variante activée, avec le même document final. Alternez les passages selon un ordre prévu afin de limiter les effets de réchauffement ou de dérive réseau. L’hébergement de recette doit permettre une observation fiable du protocole et du certificat ; n’utilisez pas un contournement de sécurité pour fabriquer un résultat positif.

Attribuer la décision, le maintien et le retour arrière

Examinez ensemble l’indication reçue, la requête anticipée, l’URL consommée et le rendu. Les erreurs de hash, les ressources inutilisées et les LCP inchangés restent dans le compte rendu. Faites qualifier les différences par frontend et plateforme avant de conclure à un défaut de l’un ou de l’autre. Le livrable doit permettre à un collègue de retrouver la navigation et ses conditions, puis de comprendre exactement quelle partie de l’hypothèse est démontrée.

Déployez ensuite sur un périmètre limité, avec un seuil de régression et une procédure de retrait indépendante des autres évolutions. Le monitoring relie la version des hints au frontend réellement servi. Vérifiez le rollback avec les caches encore présents, puis la continuité du chargement sans anticipation. L’extension attend un bénéfice utile sur la population ciblée, des ressources correctement réutilisées et des garde-fous stables. Si ces preuves manquent, gardez le diagnostic ouvert ou retirez le hint devenu sans objet.

• Si Disable cache est actif, alors isoler ce passage du pilote de préchargement 103.
• Si le CSS annoncé diffère du CSS utilisé, alors qualifier le gaspillage avant généralisation.
• Si le transfert avance mais pas le LCP, alors examiner le rendu restant sans inventer un gain.

Lectures complémentaires pour prolonger le diagnostic

Distinguer l’état de cache et la découverte des ressources

Le dossier LCP à cache froid et première visite aide à choisir les cohortes pertinentes. Il sépare les caches du navigateur, du CDN et du serveur, puis relie le protocole à l’exposition des visiteurs. Il complète la qualification spécifique des réponses 103 sans imposer une purge générale comme point de départ.

Pour une ressource découverte trop tard, l’analyse HTML, preload et Fetch Priority pour l’image LCP examine le markup et la priorité. Elle aide à décider si une correction du document suffit. L’anticipation serveur ne doit pas devenir un prétexte pour conserver une chaîne de découverte inutilement dépendante de JavaScript.

Conserver la bonne population et le bon type de navigation

Le diagnostic RUM et CrUX : expliquer les écarts entre cohortes complète la décision lorsque les données terrain semblent contredire le laboratoire. Il aide à rapprocher périodes, appareils et périmètres avant d’attribuer l’écart à une modification. Deux mesures différentes peuvent rester justes tout en répondant à des questions distinctes.

Le dossier retour arrière et ancien prix réaffiché traite la restauration d’une page et ses données métier. Ce parcours n’est pas une nouvelle arrivée avec réponse 103 à qualifier. Le distinguer dans les observations évite de présenter une restauration très rapide comme la preuve d’un meilleur chargement initial.

Conclusion : prouver l’utilisation avant d’annoncer le gain

Un statut 103 visible ne suffit pas à démontrer une optimisation. Le protocole doit laisser le mécanisme fonctionner, puis suivre la ressource jusque dans le document et le rendu. Un cache vide au départ reste compatible avec une réutilisation pendant la même navigation ; un cache désactivé pose une autre condition expérimentale.

Les 47 contrôles rendent ces différences explicites sur des observations fabriquées. Ils conservent aussi les résultats défavorables : mauvais fichier anticipé, transfert utile sans gain de LCP et régression mesurée dans la fixture. La preuve à produire sur votre site reste celle du navigateur, des versions et des visiteurs réellement concernés.

Un travail de performance et Core Web Vitals fondé sur des comparaisons recevables permet de choisir les corrections qui accélèrent le parcours, de mesurer leurs limites et de maintenir les gains après les prochaines publications.

Dawap accompagne votre SEO technique et la performance de vos pages publiques pour relier les traces réseau, le rendu, les exigences d’indexation et le déploiement progressif à des décisions vérifiables.