103 Early Hints : précharger les ressources critiques pendant le temps de calcul du serveur

Dernière révision par Arjen Karel en mars 2026

Que sont les 103 Early Hints ?

Early Hints est un code d'état HTTP (103) envoyé avant la réponse finale du serveur web. Il permet au serveur d'indiquer au navigateur, dès le début du chargement, que certaines ressources comme une image ou une feuille de style sont critiques pour le rendu de la page.

La plupart des pages dynamiques mettent du temps à être générées. Le serveur interroge une base de données, exécute la logique applicative et assemble le HTML. Pendant ce temps de calcul, le navigateur attend. Les 103 Early Hints comblent ce temps mort en indiquant au navigateur ce qu'il doit récupérer en attendant la vraie réponse.

Les Early Hints remplacent le mécanisme obsolète HTTP/2 Server Push, supprimé par Chrome dans sa version 106. Server Push intégrait les ressources à la réponse finale et transférait souvent des octets que le navigateur avait déjà en cache. Les Early Hints évitent ce problème car ils se contentent de suggérer ; le navigateur décide ensuite d'agir ou non.

Prise en charge par les navigateurs

Les 103 Early Hints sont pris en charge par 93 % des navigateurs dans le monde :

• Chrome 103+ et Edge 103+ : prise en charge complète de preconnect et preload (depuis juin 2022)
• Firefox 123+ : prise en charge complète de preconnect et preload (depuis février 2024)
• Safari 17+ : preconnect uniquement. Safari ne prend pas en charge preload dans les réponses 103

Cette limitation de Safari a son importance. Si votre stratégie d'Early Hints repose entièrement sur le preload d'images ou de polices, les utilisateurs de Safari n'en profiteront pas. Intégrez des indications preconnect aux côtés des indications preload pour que Safari amorce au moins la connexion vers les origines des ressources.

Les Early Hints fonctionnent uniquement avec HTTP/2 ou HTTP/3. Ils ne fonctionnent pas avec HTTP/1.1, depuis des iframes ou pour des requêtes hors navigation. Le navigateur traite uniquement les indications preload et preconnect ; dns-prefetch et prefetch ne sont pas pris en charge dans les réponses 103.

À quoi ressemblent les 103 Early Hints ?

Quand un navigateur demande une page, le serveur renvoie immédiatement une réponse 103 avant d'avoir fini de générer le HTML. Cette réponse indique au navigateur de commencer à télécharger l'image LCP et la feuille de style :

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Pendant ce temps, le serveur génère la page. Dès qu'elle est prête, il envoie la réponse finale :

HTTP/2 200 OK
Content-Length: 1234
[le reste de la réponse]

Quand le navigateur reçoit la réponse 200, il a déjà commencé à télécharger l'image et la feuille de style. C'est cette avance qui accélère le Largest Contentful Paint.

Comment envoyer les 103 Early Hints

Vous avez trois options principales, de la plus simple à celle offrant le plus de contrôle.

Cloudflare (le plus simple)

Si vous utilisez déjà Cloudflare pour vos performances, activer les Early Hints se résume à un simple bouton. Rendez-vous dans Speed > Settings > Content Optimization et activez Early Hints. L'option est disponible sur tous les plans, y compris l'offre gratuite.

Cloudflare met en cache les en-têtes Link des réponses 200 du serveur d'origine. Lors des requêtes suivantes, il renvoie ces en-têtes en cache sous la forme d'une réponse 103 avant de relayer la requête au serveur d'origine. Vous fournissez les indications en envoyant des en-têtes Link depuis votre application :

header("Link: </image.webp>; rel=preload; as=image", false);
header("Link: </style.css>; rel=preload; as=style", false);

NGINX (natif depuis la version 1.29.0)

NGINX a ajouté la prise en charge native des 103 Early Hints dans la version 1.29.0 (juin 2025). La directive early_hints transmet les réponses 103 du backend vers le client :

map $http_sec_fetch_mode $early_hints {
    navigate $http2$http3;
}

server {
    location / {
        early_hints $early_hints;
        proxy_pass http://backend.example.com;
    }
}

La directive map sec-fetch-mode garantit que les indications sont envoyées uniquement pour les requêtes de navigation en HTTP/2 ou HTTP/3. L'application backend doit générer la réponse 103 ; NGINX la transmet.

Apache (2.4.58+)

Apache peut générer lui-même les réponses 103 grâce à mod_http2. Activez-le avec la directive H2EarlyHints et définissez les ressources à indiquer :

H2EarlyHints on
H2EarlyHint Link "</style.css>;rel=preload;as=style"
H2EarlyHint Link "</image.webp>;rel=preload;as=image"

Contrairement à NGINX, Apache génère la réponse 103 directement au niveau du serveur, sans que l'application ait besoin de la produire.

Quand les Early Hints sont utiles (et quand ils ne le sont pas)

Les 103 Early Hints sont particulièrement efficaces lorsque le serveur met un temps notable à répondre : pages dynamiques qui interrogent des bases de données, appellent des API ou génèrent des templates. Plus le Time to First Byte est lent, plus le navigateur a de temps pour exploiter les indications.

Les Early Hints apportent moins de bénéfices quand :

• Le serveur répond en moins de 100 ms. Si le TTFB est déjà rapide, il n'y a aucun temps mort à combler pour le navigateur. Concentrez-vous plutôt sur la priorisation des ressources dans le HTML.
• Les pages sont servies depuis le cache. Une réponse HTML entièrement en cache se charge si vite que la réponse 103 n'a presque aucune avance.
• Vous indiquez trop de ressources. Indiquer plus de 10 ressources sature la connexion et peut ralentir l'ensemble. Shopify a constaté que sur mobile, des indications trop agressives entraînaient une dégradation des performances sur le TTFB, le FCP et le LCP. Limitez-vous à 2 à 4 ressources critiques.

Malgré 93 % de prise en charge par les navigateurs, l'adoption reste faible. D'après le Web Almanac 2025, seuls 5 % environ des principaux sites utilisent les 103 Early Hints. Le principal obstacle consiste à identifier les ressources à indiquer pour chaque page, ce que la plupart des CMS ne gèrent pas automatiquement.

Comment vérifier que les Early Hints fonctionnent

Ouvrez Chrome DevTools, allez dans l'onglet Réseau et rechargez la page. Cliquez sur la requête du document et examinez les en-têtes de réponse. Si les Early Hints fonctionnent, vous verrez un statut 103 avant le 200 dans le détail de la chronologie.

En ligne de commande, vous pouvez vérifier avec curl :

curl -v --http2 https://example.com 2>&1 | grep "< HTTP"

Vous devez voir à la fois une réponse 103 et une réponse 200.

Résultats des tests

J'ai testé deux scénarios pour mesurer l'impact sur le First Contentful Paint et le Largest Contentful Paint.

1. Early Hints sur l'image LCP seule

L'image LCP est apparue à l'écran 35 % plus vite avec les 103 Early Hints, par rapport à un preload classique dans le HTML.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image

2. Early Hints avec une feuille de style volumineuse et l'image LCP

L'ajout d'un fichier CSS de 85 ko aux indications a rendu la différence encore plus nette. Le FCP est passé de 1,8 seconde à 1,4 seconde, et le LCP de 3,2 secondes à 2,0 secondes.

HTTP/2 103 Early Hints
Link: </image.webp>; rel=preload; as=image
Link: </style.css>; rel=preload; as=style

Ces chiffres concordent avec ce que Cloudflare a mesuré sur plus de 100 000 clients : un gain de LCP de 6 % au 50e percentile et de 16 % au 75e percentile sur desktop. Shopify a constaté une amélioration du LCP de 500 ms au p50 pendant le Black Friday et le Cyber Monday. Les gains les plus importants concernent les pages dont le temps de réponse serveur est lent, c'est-à-dire précisément là où les Early Hints ont le plus de temps pour agir.

Early Hints et TTFB

Il y a une nuance de mesure à connaître. Depuis Chrome 133, le timing responseStart du navigateur (utilisé par la plupart des outils pour mesurer le TTFB) intègre la réponse 103. Le TTFB rapporté va donc chuter après l'activation des Early Hints, alors même que le temps de traitement réel du serveur n'a pas changé.

Pour mesurer le temps de traitement serveur séparément, Chrome 133 a introduit un nouveau timestamp firstResponseHeadersStart qui indique l'arrivée des en-têtes de la réponse finale 200. Les outils de Real User Monitoring qui suivent ces deux valeurs vous donnent une vision complète : le temps gagné par le navigateur grâce aux Early Hints et le temps réel mis par le serveur pour répondre.