Chargement des pages plus rapide grâce à l'utilisation du temps de réflexion du serveur avec les premiers conseils

Découvrez comment votre serveur peut envoyer des indices au navigateur concernant les sous-ressources critiques.

Kenji Baheux

Barry Pollard

Publié le 23 juin 2022, dernière mise à jour le 10 juillet 2026

Qu'est-ce que les premiers indices ?

Les sites Web sont devenus plus sophistiqués au fil du temps. Il n'est donc pas rare qu'un serveur doive effectuer un travail non trivial (par exemple, accéder à des bases de données ou à des CDN accédant au serveur d'origine) pour générer le code HTML de la page demandée. Malheureusement, ce "temps de réflexion du serveur" entraîne une latence supplémentaire avant que le navigateur ne puisse commencer à afficher la page. En effet, la connexion reste inactive pendant tout le temps nécessaire au serveur pour préparer la réponse.

Les premiers indices sont un code d'état HTTP (103 Early Hints) utilisé pour envoyer une réponse HTTP préliminaire avant une réponse finale. Cela permet à un serveur d'envoyer des indices au navigateur concernant les sous-ressources critiques (par exemple, les feuilles de style de la page, le code JavaScript critique) ou les origines qui seront probablement utilisées par la page, pendant que le serveur est occupé à générer la ressource principale. Le navigateur peut utiliser ces indices pour préparer les connexions et demander des sous-ressources, en attendant la ressource principale. En d'autres termes, les premiers indices aident le navigateur à tirer parti de ce "temps de réflexion du serveur" en effectuant certaines tâches à l'avance, ce qui accélère le chargement des pages.

Dans certains cas, l'amélioration des performances du Largest Contentful Paint peut passer de plusieurs centaines de millisecondes, comme l'ont observé Shopify et Cloudflare, à une seconde plus rapide, comme le montre cette comparaison avant/après :

Comment utiliser les premiers indices

La première étape pour tirer parti des premiers indices consiste à identifier les principales pages de destination, c'est-à-dire les pages sur lesquelles vos utilisateurs commencent généralement lorsqu'ils visitent votre site Web. Il peut s'agir de la page d'accueil ou de pages de fiches produits populaires si de nombreux utilisateurs proviennent d'autres sites Web. La raison pour laquelle ces points d'entrée sont plus importants que les autres pages est que l'utilité des premiers indices diminue à mesure que l'utilisateur navigue sur votre site Web (c'est-à-dire que le navigateur est plus susceptible de disposer de toutes les sous-ressources dont il a besoin lors de la deuxième ou de la troisième navigation suivante). Il est également toujours judicieux de faire une bonne première impression.

Maintenant que vous disposez de cette liste de pages de destination prioritaires, l'étape suivante consiste à identifier les origines ou les sous-ressources qui seraient de bons candidats pour les indices preconnect ou preload. En règle générale, il s'agit d'origines et de sous-ressources qui contribuent le plus aux métriques utilisateur clés telles que Largest Contentful Paint ou First Contentful Paint. Plus concrètement, recherchez les sous-ressources bloquant le rendu, telles que le code JavaScript synchrone, les feuilles de style ou même les polices Web. De même, recherchez les origines qui hébergent des sous-ressources qui contribuent beaucoup aux métriques utilisateur clés.

Notez également que si vos ressources principales utilisent déjà preconnect ou preload, vous pouvez envisager ces origines ou ressources parmi les candidats pour les premiers indices. Pour en savoir plus, consultez la section Optimiser le LCP. Toutefois, copier naïvement les directives preconnect et preload du code HTML vers les premiers indices n'est peut-être pas optimal.

Lorsque vous les utilisez en HTML, vous devez généralement preconnect ou preload les ressources que le scanner de préchargement ne détecte pas dans le code HTML, par exemple les polices ou les images d'arrière-plan qui seraient détectées tardivement. Pour les premiers indices, vous n'aurez pas le code HTML. Vous pouvez donc preconnect à des domaines critiques ou preload des ressources critiques qui seraient peut-être détectées tôt dans le code HTML, par exemple en préchargeant main.css ou app.js.De plus, tous les navigateurs ne sont pas compatibles avec preload pour les premiers indices. Consultez la section Prise en charge des navigateurs.

La seconde étape consiste à minimiser le risque d'utiliser les premiers indices sur des ressources ou des origines qui peuvent être obsolètes ou ne plus être utilisées par la ressource principale. Par exemple, les ressources fréquemment mises à jour et versionnées (par exemple, example.com/css/main.fa231e9c.css) ne sont peut-être pas le meilleur choix. Notez que ce problème n'est pas spécifique aux premiers indices. Il s'applique à tous les preload ou preconnect où qu'ils soient présents. Il est préférable de gérer ce type de détail avec l'automatisation ou les modèles (par exemple, un processus manuel est plus susceptible d'entraîner des URL de hachage ou de version non concordantes entre preload et la balise HTML réelle utilisant la ressource).

Prenons l'exemple du flux suivant :

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

Le serveur prédit que main.abcd100.css sera nécessaire et suggère de le précharger à l'aide des premiers indices :

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

Quelques instants plus tard, la page Web, y compris le code CSS associé, est diffusée. Malheureusement, cette ressource CSS est fréquemment mise à jour, et la ressource principale a déjà cinq versions d'avance (abcd105) sur la ressource CSS prédite (abcd100).

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

En général, visez des ressources et des origines relativement stables et largement indépendantes du résultat de la ressource principale. Si nécessaire, vous pouvez envisager de diviser vos ressources clés en deux : une partie stable conçue pour être utilisée avec les premiers indices et une partie plus dynamique à récupérer une fois la ressource principale reçue par le navigateur :

<html>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

Enfin, côté serveur, recherchez les requêtes de ressources principales envoyées par les navigateurs compatibles avec les premiers indices et répondez immédiatement avec 103 premiers indices. Dans la réponse 103, incluez les indices de préconnexion et de préchargement pertinents. Une fois la ressource principale prête, effectuez un suivi avec la réponse habituelle (par exemple, 200 OK en cas de succès). Pour la rétrocompatibilité, il est recommandé d'inclure également des en-têtes HTTP Link dans la réponse finale, voire d'ajouter des ressources critiques qui sont devenues évidentes lors de la génération de la ressource principale (par exemple, la partie dynamique d'une ressource clé si vous avez suivi la suggestion de division en deux). Voici à quoi cela ressemblerait :

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

Quelques instants plus tard :

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

Prise en charge des navigateurs

Bien que 103 premiers indices soient compatibles avec tous les principaux navigateurs, les directives qui peuvent être envoyées sur un premier indice diffèrent selon le navigateur :

Prise en charge de la préconnexion :

Prise en charge du préchargement :

Les Outils pour les développeurs Chrome sont également compatibles avec 103 premiers indices, et les en-têtes Link sont visibles sur les ressources du document :

Notez que pour utiliser les ressources des premiers indices, l'option Disable cache ne doit pas être cochée dans les Outils de développement, car les premiers indices utilisent le cache du navigateur. Pour les ressources préchargées, l'initiateur s'affiche sous la forme Early-hints et la taille sous la forme (Disk cache) :

Cela nécessite également un certificat approuvé pour les tests HTTPS.

Firefox n'est pas explicitement compatible avec 103 premiers indices en tant qu'initiateur dans les Outils pour les développeurs, mais les ressources chargées à l'aide des premiers indices s'affichent sous la forme cached dans la colonne Transferred (Transféré) et, lorsque vous cliquez dessus, elles comportent un en-tête de requête HTTP X-Moz: early hint.

Support serveur

Voici un bref résumé du niveau de prise en charge des premiers indices parmi les logiciels de serveur HTTP Open Source populaires :

• Apache : compatible avec mod_http2.
• H2O : compatible.
• NGINX : compatible.
• Node : compatible avec http et http2

Activer les premiers indices plus facilement

Si vous utilisez l'un des CDN ou plates-formes suivants, vous n'aurez peut-être pas besoin d'implémenter manuellement les premiers indices. Consultez la documentation en ligne de votre fournisseur de solution pour savoir s'il est compatible avec les premiers indices ou consultez la liste non exhaustive ci-dessous :

• Premiers indices dans Cloudflare
• Premiers indices dans Fastly.
• Premiers indices dans Akamai.

Comment éviter les problèmes pour les clients qui ne sont pas compatibles avec les premiers indices

Les réponses HTTP informatives comprises entre 100 et 199 font partie de la norme HTTP, mais certains clients ou robots plus anciens peuvent avoir des difficultés avec ces réponses, car avant le lancement de 103 premiers indices, elles étaient rarement utilisées pour la navigation Web générale.

N'émettre que 103 premiers indices en réponse aux clients qui envoient un en-tête de requête HTTP sec-fetch-mode: navigate ne doit envoyer ces indices qu'aux clients plus récents qui comprennent qu'ils doivent attendre la réponse suivante. De plus, comme les premiers indices ne sont compatibles qu'avec les requêtes de navigation (voir les limites actuelles), cela présente l'avantage supplémentaire d'éviter de les envoyer inutilement sur d'autres requêtes.

En outre, il est recommandé de n'envoyer les premiers indices que via des connexions HTTP/2 ou HTTP/3, et la plupart des navigateurs ne les accepteront que via ces protocoles.

Modèle avancé

Si vous avez entièrement appliqué les premiers indices à vos principales pages de destination et que vous recherchez d'autres opportunités, le modèle avancé suivant peut vous intéresser.

Pour les visiteurs qui en sont à leur nième requête de page dans le cadre d'un parcours utilisateur type, vous pouvez adapter la réponse des premiers indices au contenu situé plus bas et plus loin dans la page, en d'autres termes, en utilisant les premiers indices sur des ressources de priorité inférieure. Cela peut sembler contre-intuitif, car nous vous avons recommandé de vous concentrer sur les sous-ressources ou les origines bloquant le rendu et de haute priorité. Toutefois, lorsqu'un visiteur a navigué pendant un certain temps, il est très probable que son navigateur dispose déjà de toutes les ressources critiques. À partir de là, il peut être judicieux de vous concentrer sur les ressources de priorité inférieure. Par exemple, cela peut signifier utiliser les premiers indices pour charger des images de produits ou du code JS/CSS supplémentaire qui n'est nécessaire que pour les interactions utilisateur moins courantes.

Limites actuelles

Voici les limites des premiers indices tels qu'ils sont implémentés dans Chrome :

• Disponible uniquement pour les requêtes de navigation (c'est-à-dire la ressource principale du document de niveau supérieur).
• Compatible uniquement avec preconnect et preload (c'est-à-dire que prefetch n'est pas compatible).
• Les premiers indices suivis d'une redirection inter-origine dans la réponse finale entraînent l'abandon par les navigateurs des ressources et des connexions qu'ils ont obtenues à l'aide des premiers indices.
• Les ressources préchargées à l'aide des premiers indices sont stockées dans le cache HTTP et récupérées à partir de là par la page ultérieurement. Par conséquent, seules les ressources pouvant être mises en cache peuvent être préchargées à l'aide des premiers indices, sinon la ressource sera récupérée deux fois (une fois par les premiers indices et une fois par le document). Dans Chrome, le cache HTTP est désactivé pour les certificats HTTPS non approuvés (même si vous chargez la page).
• Le préchargement d'images responsives (à l'aide de imagesrcset, imagesizes ou media) n'est peut-être pas compatible avec les en-têtes HTTP <link> headers, car la fenêtre d'affichage n'est pas définie tant que le document n'est pas créé. Au mieux, ils attendront que le document soit reçu, ce qui annulera les principaux avantages de 103 premiers indices.

D'autres navigateurs présentent des limites similaires et, comme indiqué précédemment, certains limitent davantage les 103 premiers indices à preconnect uniquement.

Relation avec H2/Push

Si vous connaissez la fonctionnalité HTTP2/Push obsolète, vous vous demandez peut-être en quoi les premiers indices diffèrent. Alors que les premiers indices nécessitent un aller-retour pour que le navigateur commence à récupérer les sous-ressources critiques, avec HTTP2/Push, le serveur peut commencer à envoyer des sous-ressources en même temps que la réponse. Bien que cela semble incroyable, cela a entraîné un inconvénient structurel majeur : avec HTTP2/Push, il était extrêmement difficile d'éviter d'envoyer des sous-ressources que le navigateur possédait déjà. Cet effet de "sur-envoi" a entraîné une utilisation moins efficace de la bande passante réseau, ce qui a considérablement entravé les avantages en termes de performances. Dans l'ensemble, les données Chrome ont montré que HTTP2/Push était en fait un inconvénient net pour les performances sur le Web.

En revanche, les premiers indices sont plus performants en pratique, car ils combinent la possibilité d'envoyer une réponse préliminaire avec des indices qui laissent le navigateur responsable de la récupération ou de la connexion à ce dont il a réellement besoin. Bien que les premiers indices ne couvrent pas tous les cas d'utilisation que HTTP2/Push pourrait théoriquement traiter, nous pensons qu'il s'agit d'une solution plus pratique pour accélérer la navigation.

Vignette de l'image par Pierre Bamin.