Que signifie le code HTTP 103 Early Hints ?

Le code HTTP 103 Early Hints est une réponse informative provisoire envoyée par un serveur avant sa réponse définitive. Son objectif est simple : signaler au navigateur certaines ressources utiles pendant que le serveur termine un traitement plus long, par exemple le rendu d’une page dynamique ou l’appel à des services internes. Le navigateur peut alors commencer à récupérer ces fichiers sans attendre le statut final, généralement 200, 302 ou 404. Ce mécanisme vise surtout à réduire les temps morts au début du chargement.

Définition du code HTTP 103 Early Hints

Une réponse provisoire envoyée avant le statut final

HTTP 103 appartient à la famille des statuts 1xx, réservés aux informations intermédiaires. Il ne décrit donc pas le résultat final de la requête : il annonce seulement des indications exploitables immédiatement par le client. Une même requête peut recevoir un 103, puis quelques instants plus tard une réponse finale complète. Le serveur n’envoie pas de corps de réponse avec un 103. Il transmet principalement des en-têtes, notamment Link, afin d’indiquer des ressources à précharger. Le navigateur n’est pas obligé de les utiliser, mais il peut lancer les téléchargements avant que le document HTML ne soit disponible. Le statut a été standardisé pour résoudre un problème fréquent : lorsqu’une page dépend d’un calcul côté serveur, le navigateur ne découvre les feuilles de style, polices ou scripts critiques qu’après réception du HTML. Early Hints permet de raccourcir cette attente.

La différence entre les codes 103, 102 et 200

Code	Rôle	Effet pour le navigateur
102 Processing	Indique qu’une requête, notamment WebDAV, est en cours de traitement.	Évite surtout une attente sans information ; il ne sert pas à précharger des ressources.
103 Early Hints	Communique tôt des en-têtes susceptibles d’être utiles.	Peut déclencher le chargement anticipé de fichiers critiques.
200 OK	Confirme le succès et fournit la réponse attendue.	Apporte le HTML, les données ou la ressource finale.

Le code 103 ne remplace donc jamais le 200 ou tout autre statut final. À l’inverse, le code 304 répond à une logique de cache : il confirme qu’une ressource n’a pas besoin d’être retransférée. Pour approfondir ce point, consultez le fonctionnement du code HTTP 304 Not Modified.

Le fonctionnement de HTTP 103 dans le chargement d’une page

L’envoi anticipé des en-têtes Link

Le cas d’usage classique consiste à envoyer un en-tête semblable à : Link: </assets/site.css>; rel=preload; as=style. Le serveur peut le transmettre dès qu’il connaît les ressources stables de la page, même si le contenu final n’est pas encore prêt. Les indications doivent rester cohérentes avec la réponse définitive. Un 103 peut aussi transmettre des informations relatives à la connexion vers des ressources externes, mais son intérêt principal demeure le préchargement. Les en-têtes ne doivent pas dépendre d’un résultat encore incertain, comme une page personnalisée selon les droits de l’utilisateur.

Le préchargement des ressources critiques par le navigateur

À la réception du 103, le navigateur évalue les directives reçues et peut initier les requêtes réseau. Cette avance est particulièrement utile pour une feuille CSS indispensable à l’affichage, une police réellement utilisée au-dessus de la ligne de flottaison, ou un script nécessaire au démarrage de l’interface. Le gain dépend de la durée séparant le 103 de la réponse finale et du coût de téléchargement des ressources. Si le HTML arrive presque instantanément, l’avantage est souvent marginal. Il dépend aussi de la négociation du protocole et de la connexion. Le rôle de la négociation ALPN avec HTTP/2 aide notamment à comprendre comment client et serveur choisissent leur protocole applicatif.

La réponse finale du serveur après les Early Hints

Après le 103, le serveur envoie sa réponse normale avec ses propres en-têtes et son corps. Le navigateur doit traiter cette dernière comme la source d’autorité. Si elle redirige vers une autre page, refuse l’accès ou renvoie une erreur, les téléchargements commencés grâce aux Early Hints peuvent ne plus être utiles. Early Hints accélère une phase du chargement ; il ne garantit pas une page plus rapide dans tous les cas. Il ne réduit ni un traitement serveur trop long, ni le poids des fichiers, ni les éventuels blocages JavaScript.

Les bénéfices et les cas d’usage pertinents

Réduire le temps d’attente des ressources CSS, JavaScript et polices

Le mécanisme est le plus pertinent lorsque le serveur connaît à l’avance les dépendances communes à une page, mais produit le HTML avec un délai perceptible. Un site peut, par exemple, annoncer sa feuille de style principale avant de terminer une requête vers une base de données. Les ressources candidates doivent respecter trois critères :

• elles sont critiques pour le premier affichage ou l’interactivité initiale ;
• elles seront très probablement demandées par la réponse finale ;
• leur téléchargement anticipé ne concurrence pas des fichiers plus importants.

Améliorer l’affichage initial des pages dont la réponse est lente

Les pages rendues côté serveur, les catalogues enrichis à la demande et les interfaces composées de plusieurs services peuvent bénéficier de cette anticipation. Le navigateur avance pendant que le serveur attend une donnée ou assemble le document. HTTP/3 peut aussi réduire certaines latences de transport grâce à QUIC, mais il s’agit d’un levier distinct. Le protocole QUIC utilisé par HTTP/3 améliore la communication réseau ; 103 anticipe la découverte des ressources.

Les situations où Early Hints apporte peu de gains

L’intérêt est faible lorsque la réponse finale est déjà très rapide, lorsque toutes les ressources critiques sont servies depuis le cache du navigateur, ou lorsque les fichiers changent selon chaque visiteur. Il est également limité si la page contient peu de ressources bloquantes. Un préchargement prématuré peut même pénaliser le chargement en occupant bande passante, connexions et priorités réseau. La présence d’un 103 ne constitue pas, à elle seule, une amélioration mesurable.

Mettre en place HTTP 103 Early Hints

Identifier les ressources réellement critiques à précharger

Commencez par observer la cascade réseau d’une page représentative. Recherchez les fichiers découverts tardivement mais nécessaires au premier rendu. Une feuille CSS principale est souvent un meilleur candidat qu’une image secondaire, un module facultatif ou un script chargé après interaction. Il faut aussi vérifier que le fichier annoncé possède l’attribut approprié : une police exige notamment son type et, selon le cas, son mode crossorigin. Une directive imprécise peut entraîner un téléchargement inutile ou non réutilisable.

Configurer les en-têtes Link sur le serveur, le CDN ou le framework

La mise en œuvre dépend de l’architecture : serveur web, CDN, proxy inverse ou framework applicatif. Le composant choisi doit pouvoir émettre une réponse 103 avant que la réponse finale ne soit disponible. Les ressources annoncées doivent rester identiques entre les couches de diffusion afin d’éviter des indications obsolètes. Le comportement HTTP s’appuie sur des spécifications formelles : le rôle des RFC dans les standards Internet explique ce cadre technique. En pratique, consultez aussi la documentation du serveur et du CDN utilisés, car leur prise en charge diffère.

Vérifier la réception du statut 103 et le comportement du navigateur

Les outils réseau du navigateur, les journaux du CDN et des commandes HTTP permettent de confirmer la présence du statut intermédiaire et des en-têtes Link. Testez ensuite une page sans cache, sur plusieurs navigateurs et dans des conditions réseau réalistes. La vérification doit porter sur les requêtes réellement avancées, pas seulement sur l’existence du 103. Si le navigateur récupère le même fichier au même moment qu’auparavant, la configuration n’apporte pas le bénéfice attendu.

Limites et erreurs à éviter avec Early Hints

Précharger trop de fichiers ou des ressources non prioritaires

L’erreur la plus courante consiste à annoncer toutes les ressources d’une page. Les images décoratives, scripts d’analyse, composants différés et variantes non utilisées ne doivent généralement pas figurer dans les Early Hints. Chaque préchargement engage des ressources réseau limitées.

Envoyer des indications incompatibles avec la réponse finale

Une ressource annoncée dans le 103 puis absente du document final représente un gaspillage potentiel. Le risque augmente avec la personnalisation, les tests d’interface, les redirections et les pages dont les dépendances varient selon la session. Limitez les indices aux fichiers communs, stables et fortement probables.

Ne pas tenir compte de la prise en charge par les navigateurs et intermédiaires

Les navigateurs, CDN, proxys et serveurs ne traitent pas tous les réponses intermédiaires de manière identique. Certains peuvent ignorer le 103, le transmettre différemment ou ne pas permettre sa génération dans une configuration donnée. Il faut donc concevoir Early Hints comme une optimisation progressive : la page doit rester correcte et performante autant que possible sans ce mécanisme.

Early Hints : une optimisation à utiliser avec précision

Le code HTTP 103 permet au navigateur de découvrir certaines ressources avant l’arrivée de la réponse finale. Son intérêt repose sur une idée simple : exploiter le temps de traitement serveur pour commencer le chargement des fichiers réellement nécessaires à l’affichage initial. Il ne remplace toutefois ni une réponse rapide, ni une bonne gestion du cache, ni des ressources légères. Son efficacité dépend surtout de la sélection des fichiers annoncés. Précharger peu de ressources, mais les bonnes, évite de mobiliser inutilement la bande passante et les priorités réseau. Les en-têtes doivent aussi rester cohérents avec le contenu finalement envoyé. Avant un déploiement généralisé, il est préférable de mesurer le comportement réel des navigateurs, du CDN et des pages concernées afin de confirmer un gain concret.