Early Hints HTTP 103 est un code de statut HTTP encore méconnu qui permet au navigateur de commencer à charger certaines ressources avant même que le serveur ait fini de préparer la réponse principale. Pour un site soumis à des traitements serveur lourds (base de données, génération dynamique, cache froid), ce gain de quelques centaines de millisecondes peut faire basculer un Core Web Vital d’une zone orange à une zone verte.
Dans ce guide, nous détaillons le fonctionnement de ce mécanisme, sa mise en place concrète sur un serveur ou un CDN, ses différences avec les Resource Hints classiques, et la méthode pour mesurer son impact réel sur la performance perçue.
Qu’est-ce que Early Hints HTTP 103 ?
Early Hints HTTP 103 est un code de statut HTTP informationnel défini par la RFC 8297, publiée par l’IETF. Il permet au serveur d’envoyer une réponse préliminaire contenant des en-têtes Link (preload, preconnect, dns-prefetch) pendant qu’il continue de construire la réponse finale, généralement un code 200.
Concrètement, le navigateur reçoit ces indices très tôt et peut lancer les connexions ou les téléchargements concernés sans attendre que le serveur ait terminé son traitement, souvent l’étape la plus lente de la chaîne pour les pages générées dynamiquement.
Comment fonctionne le mécanisme Early Hints HTTP 103
Le fonctionnement d’Early Hints HTTP 103 repose sur une particularité du protocole HTTP : une même requête peut recevoir plusieurs réponses informationnelles (codes 1xx) avant la réponse finale. Le serveur envoie d’abord un message 103 contenant les en-têtes Link, puis poursuit son traitement normal avant d’envoyer le code 200 avec le contenu complet.
Un site e-commerce qui doit interroger sa base de données pour afficher une fiche produit peut ainsi envoyer un 103 avec un en-tête Link: </style.css>; rel=preload dès la réception de la requête, alors que la requête SQL est encore en cours d’exécution côté serveur.
Mettre en place Early Hints HTTP 103 sur son serveur
La mise en place d’Early Hints HTTP 103 nécessite un serveur web ou un reverse proxy capable d’émettre des réponses 103, ce que ne font pas encore nativement tous les logiciels. Nginx propose un support via configuration spécifique, tandis qu’Apache nécessite un module tiers encore peu répandu.
Pour un site WordPress classique, la solution la plus simple reste de passer par un CDN qui gère cette fonctionnalité nativement : le serveur d’origine continue de fonctionner normalement, et c’est le CDN qui génère la réponse 103 à partir des en-têtes déjà connus (feuilles de style, polices, scripts critiques).
Early Hints HTTP 103 chez les CDN (Cloudflare, Fastly)
Cloudflare a été l’un des premiers CDN à proposer cette fonctionnalité en configuration simple : il suffit d’activer l’option dans le tableau de bord et de définir, via les règles de transformation ou un Worker, les en-têtes Link à précharger pour chaque type de page.
Fastly propose une approche similaire via ses services Compute, et Chrome supporte Early Hints HTTP 103 depuis plusieurs versions déjà. Avant de l’activer, il est recommandé de vérifier la compatibilité du CDN en place, car tous les fournisseurs ne l’ont pas encore déployé.
Early Hints HTTP 103 face aux Resource Hints classiques
Early Hints HTTP 103 ne remplace pas les balises <link rel="preload">, preconnect ou dns-prefetch posées directement dans le HTML : il les complète en les déclenchant beaucoup plus tôt, avant même que le navigateur ait reçu le premier octet du document. Pour aller plus loin sur ces balises posées dans le <head>, consultez notre guide sur le préchargement des ressources.
La différence est cruciale pour les pages générées dynamiquement : sans ce mécanisme, le navigateur doit attendre la réponse complète du serveur avant de découvrir les ressources à précharger, ce qui annule une bonne partie du bénéfice sur les pages lentes à générer côté serveur.
Impact d’Early Hints HTTP 103 sur les Core Web Vitals
L’impact d’Early Hints HTTP 103 se mesure surtout sur le Largest Contentful Paint (LCP) et le temps de premier octet perçu, puisque les ressources critiques (police principale, CSS, image héro) commencent à se charger pendant que le serveur travaille encore sur le HTML.
Sur les sites dont le backend est lent (temps de réponse serveur supérieur à 600 ms), les gains observés se situent souvent entre 100 et 300 ms sur le LCP, un écart suffisant pour faire passer certaines pages du seuil « à améliorer » au seuil « bon » dans Google Search Console.
Mesurer les gains d’Early Hints HTTP 103
Pour mesurer ces gains, il faut comparer les métriques de chargement avant et après activation à l’aide d’un outil comme WebPageTest ou Chrome DevTools, en observant la timeline réseau : les requêtes déclenchées par le code 103 doivent apparaître avant la fin du téléchargement du document HTML.
L’onglet Réseau de Chrome DevTools affiche une ligne « 103 Early Hints » distincte suivie du « 200 OK » final sur la même requête ; si cette ligne n’apparaît pas, le serveur ou le CDN n’envoie pas encore la réponse préliminaire correctement.
Conclusion
Early Hints HTTP 103 reste une optimisation encore peu répandue, mais particulièrement rentable sur les sites dont le temps de génération serveur est significatif. Associé à une stratégie de préchargement classique, ce code de statut permet de récupérer plusieurs centaines de millisecondes sans toucher au code applicatif.
Pour approfondir les fondamentaux du protocole, la documentation officielle Early Hints sur Chrome Developers détaille l’implémentation côté navigateur et les cas d’usage recommandés.