Premiers conseils, chargements de page plus rapides en utilisant le temps d'attente du serveur avec HTTP 103

Vous voulez connaître un secret sur les performances Internet ? Les navigateurs passent un temps démesuré à se tourner les pouces en attendant de savoir quoi faire. Cette attente affecte les performances de chargement de la page. Aujourd'hui, nous sommes heureux de discuter de ce que sont les premiers conseils, qui améliorent considérablement les performances de chargement des pages du navigateur et réduisent le temps d'attente.

Que sont les premiers conseils ?

Si nous traduisons littéralement le terme "Early Hints", nous obtiendrons "First Suggestions" en italien. Ce terme est certainement beaucoup plus immédiat et éloquent pour mieux comprendre la fonctionnalité proposée dès 2017 qui voit le jour vers la fin juin 2022.

Les sites Web sont devenus plus sophistiqués au fil du temps. Par conséquent, il n'est pas rare qu'un serveur effectue un travail non trivial (par exemple, accéder à des bases de données ou à des CDN accédant au serveur d'origine) pour produire le code HTML de la page demandée. Malheureusement, ce « temps de réflexion du serveur », techniquement appelé « Temps de réflexion », entraîne une latence supplémentaire avant que le navigateur ne puisse commencer à afficher la page. En effet, la connexion reste inactive aussi longtemps que le serveur prépare la réponse.

Early Hints est 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 suggestions au navigateur concernant des sous-ressources critiques (par exemple, feuille de style pour la page, JavaScript critique) ou des sources 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 conseils pour chauffer les connexions et demander des ressources secondaires en attendant la ressource principale. En d'autres termes, Early Hints aide le navigateur à tirer parti de ce "temps de réflexion du serveur" en effectuant certaines tâches à l'avance, accélérant ainsi le chargement de la page.

Dans certains cas, les gains de performance pour le Contentful Paint de grande taille peuvent aller de plusieurs centaines de millisecondes, comme l'ont observé Shopify et Cloudflare , jusqu'à une seconde de gain, comme le montre cette comparaison avant/après :

La page ne peut pas être rendue (et l'acheteur ne peut pas obtenir la dose de café et le café ne peut pas être payé !) Tant que les éléments clés ne sont pas chargés. Les informations sur les sous-ressources nécessaires au navigateur pour charger la page ne sont pas disponibles tant que le serveur n'a pas attendu et renvoyé la réponse initiale (le premier document du tableau ci-dessus).

Dans l'exemple précédent, le chargement de la page aurait pu être accéléré si le navigateur avait su, avant de recevoir la réponse complète, que la feuille de style et les quatre scripts suivants seraient nécessaires pour rendre la page.

L'objectif d'Early Hints est de paralléliser cette dépendance : utiliser efficacement le temps d'attente du serveur pour permettre au navigateur d'effectuer les étapes critiques du rendu de la page avant même la réception de la réponse complète. La barre verte « En cours de traitement » se superpose à la barre bleue « Téléchargement du contenu », permettant ainsi au navigateur et au serveur de préparer la page simultanément. Fini l'attente ! C'est tout le principe d'Early Hints !

« Les entrepreneurs savent que la première impression compte. Les données de Shopify montrent qu'en moyenne, lorsqu'un magasin améliore de 10 % la vitesse de la première page du parcours de l'acheteur, il y a une augmentation de 7 % des conversions. Nous pensons que Early Hints est très prometteur comme un autre outil pour aider à améliorer les performances et l'expérience de tous les marchands et clients."
- Colin Bendel , directeur de l'ingénierie des performances de Shopify

Mise en œuvre des premiers conseils

Early Hints est disponible à partir de la version 103 de Chrome, en réponse aux demandes de navigation ou aux interactions des utilisateurs qui modifient l'URL dans la barre d'état, avec prise en charge des suggestions de préconnexion et de préchargement.

Avant d'approfondir le sujet, gardez à l'esprit que les suggestions initiales ne sont pas utiles si votre serveur peut immédiatement envoyer un 200 (ou d'autres réponses finales). Au lieu de cela, envisagez d'utiliser la réponse normale link rel=preloado link rel=preconnectsur la réponse principale ( Lien rel en-tête HTTP ) ou dans la réponse principale ( <link>éléments), dans de telles situations. Pour les cas où votre serveur a besoin de temps pour générer la réponse principale, lisez la suite !

Pour le dire franchement, malgré toute la virtuosité technique, si vous utilisez un cache statique efficace avec un temps de réponse initial très court et rapide (moins de 200 ms), les indications précoces n'offriront probablement aucun avantage tangible, sauf peut-être de l'ordre de quelques millisecondes.

La première étape pour tirer parti des premiers conseils consiste à identifier vos principales pages de destination - les pages à partir desquelles 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 liste de produits populaires si vous avez beaucoup d'utilisateurs d'autres sites Web. La raison pour laquelle ces points d'entrée sont plus importants que d'autres pages est que l'utilité des premiers conseils diminue à mesure que l'utilisateur navigue sur votre site Web (c'est-à-dire , le navigateur est plus susceptible d'avoir toutes les sous-ressources dont il a besoin dans la seconde ou la troisième navigation suivante). C'est toujours une bonne idée de faire une bonne première impression aussi!

Maintenant que vous avez cette liste prioritaire de landing pages, la prochaine étape consiste à identifier quelles sources ou sous-ressources seraient de bons candidats pour vos suggestions. pré-connexion o précharger , en première approximation. En règle générale, il s'agit de sources et de ressources secondaires qui contribuent le plus aux mesures clés des utilisateurs, telles que La plus grande peinture riche en contenu o Première peinture contentieuse . Plus concrètement, recherchez des ressources secondaires qui bloquent le rendu telles que le JavaScript synchrone, les feuilles de style ou même les polices Web. De même, recherchez des sources qui hébergent des sous-ressources qui contribuent beaucoup aux mesures clés des utilisateurs. Remarque : si vos éléments principaux utilisent déjà <link rel=preconnect>o<link rel=preload>, vous pouvez considérer ces sources ou actifs comme des candidats pour Early Hints. Vous voyez cet article pour plus de détails.

Bien que ce soit un bon point de départ, ce n'est pas nécessairement suffisant. La deuxième étape consiste à minimiser le risque d'utiliser les premiers conseils sur des ressources ou des sources qui peuvent être obsolètes ou ne plus être utilisées par la ressource principale. Par exemple, les ressources mises à jour fréquemment et avec la version (par exemple example.com/css/main.fa231e9c.css) n'est peut-être pas le meilleur choix. Notez que ce problème n'est pas spécifique à Early Hints, il s'applique à n'importe quel lien rel=preloado rel=preconnectpartout où ils pourraient être présents. C'est le type de détail qui est le mieux traité avec l'automatisation ou la modélisation (par exemple, un processus manuel est plus susceptible d'entraîner des URL de hachage ou de version incompatibles entre link rel=preloadet la balise HTML réelle utilisée par la ressource).

Par exemple, considérons le flux suivant :

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

Le serveur s'attend à ce que main.abcd100.csssera nécessaire et suggère de le précharger via Early Hints :

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

Quelques instants plus tard, la page Web est servie, y compris le CSS lié. Malheureusement, cette ressource CSS est fréquemment mise à jour et la ressource principale a déjà cinq versions d'avance ( abcd105) de la ressource CSS attendue ( abcd100).

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

En général, visez des sources et des origines qui sont assez stables et largement indépendantes du résultat pour la ressource primaire. Si nécessaire, vous pouvez envisager de diviser vos actifs clés en deux : une partie stable conçue pour être utilisée avec Early Hints et une partie plus dynamique laissée à récupérer après la réception de la ressource principale 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 principales demandes de ressources envoyées par les navigateurs connus pour prendre en charge les Early Hints et répondez immédiatement avec 103 Early Hints. Dans la réponse 103, incluez des suggestions pertinentes de préconnexion et de préchargement. Une fois que la ressource principale est prête, continuez avec la réponse habituelle (par exemple, 200 OK en cas de succès). Pour la rétrocompatibilité, c'est une bonne idée d'inclure également LinkEn-têtes HTTP dans la réponse finale, augmentant peut-être même avec des ressources critiques qui sont devenues apparentes dans le cadre de la génération de la ressource principale (par exemple, la partie dynamique d'une ressource clé si vous avez suivi l'astuce "diviser 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 premiers conseils pour divers serveurs Web HTTP

Voici un bref résumé du niveau de prise en charge d'Early Hints parmi les logiciels de serveur HTTP OSS les plus populaires :

• Apache: soutenu via mod_http2.
• H2O: soutenu .
• NGINX : module expérimental .
• Nœud: pas encore pris en charge par le noyau. Disponible en brouillon de plug-in pour Fastify .

Il convient de noter que Cloudflare utilise le serveur web NGINX (prononcé Engine X) . Compte tenu du dynamisme de l'entreprise et de son intérêt pour l'open source, ce correctif (comme ce fut le cas pour le correctif QUIC) pourrait également être déployé pour NGINX. Dans le cas contraire, nous sommes convaincus que l'équipe de développement du serveur web NGINX intégrera cette fonctionnalité d'ici 6 à 12 mois.

Activer les premiers conseils, le moyen le plus simple

Si vous utilisez l'un des CDN ou plates-formes suivants, vous n'aurez peut-être pas besoin de mettre en œuvre manuellement les conseils initiaux. Reportez-vous à la documentation en ligne de votre fournisseur de solutions pour savoir s'il prend en charge les suggestions initiales, ou reportez-vous à la liste non exhaustive ici :

• Premiers conseils sur Cloudflare

Premiers conseils sur CloudFlare

Cloudflare, en tant que réseau de périmètre situé entre le client et le serveur, est bien placé pour fournir ces conseils aux clients au nom des serveurs. Cela est vrai pour plusieurs raisons :

1. 103 est un code de statut expérimental que les origines peuvent ne pas être en mesure d'émettre par elles-mêmes, principalement pour des raisons d'héritage. Une grande partie des mécanismes qui alimentent le Web présupposent à tort Les requêtes HTTP correspondent toujours 1 : 1 avec les réponses HTTP. Cette prémisse erronée est intégrée à la plupart des logiciels de serveur HTTP, ce qui rend difficile pour les serveurs d'origine d'émettre des réponses Early Hints 103 avant une réponse "finale" 200 OK.
   Les serveurs périphériques Cloudflare qui gèrent cette complexité pour le compte de nos clients échappent parfaitement à ces défis techniques et font tourner plus rapidement le volant d'inertie de cette nouvelle technologie passionnante (nous en reparlerons plus tard).
2. L'avantage de Cloudflare est très proche des utilisateurs finaux . Cela signifie que nous pouvons fournir des suggestions très rapidement, remplissant même les plus petits blocs de réflexion du serveur avec des informations utiles que le client peut utiliser pour commencer à charger les ressources immédiatement.
3. Cloudflare voit déjà le flux de demandes et de réponses de nos clients. Nous utilisons ces données pour générer automatiquement des recommandations, sans qu'un client n'ait à modifier la source.

Modèle avancé

Si vous avez entièrement appliqué les conseils initiaux à vos principales pages de destination et que vous vous trouvez à la recherche de plus d'opportunités, vous serez peut-être intéressé par le plan avancé suivant.

Pour les visiteurs qui consultent plusieurs pages simultanément, il peut être judicieux d'adapter la réponse des indications préliminaires au contenu situé plus bas sur la page, c'est-à-dire aux ressources de moindre priorité. Cela peut sembler paradoxal, étant donné que nous recommandons de privilégier les ressources prioritaires ou les ressources secondaires qui bloquent l'affichage. Cependant, après un certain temps de navigation, le navigateur d'un visiteur est probablement déjà chargé avec toutes les ressources essentielles. Dès lors, il peut être pertinent de se concentrer sur les ressources de moindre priorité. Par exemple, cela pourrait impliquer l'utilisation des indications préliminaires pour charger les images de produits ou les fichiers JS/CSS supplémentaires nécessaires uniquement pour les interactions utilisateur moins fréquentes.

Limites actuelles des premiers conseils

Voici les limites des premiers conseils mis en œuvre dans Chrome 103 et les versions futures jusqu'à nouvel ordre :

• Disponible uniquement pour les demandes de navigation (qui est la ressource principale du document de niveau supérieur).
• Il ne prend en charge que la préconnexion et le préchargement (c'est-à-dire que le préchargement n'est pas pris en charge).
• Early Hint suivi d'une redirection multi-origine sur la réponse finale entraînera la suppression par Chrome des ressources et des connexions obtenues via Early Hints.

Quelle est la prochaine étape?

En fonction de l'intérêt de la communauté, nous pouvons augmenter notre implémentation Early Hints avec les fonctionnalités suivantes :

• Suggestions initiales envoyées sur les demandes de sous-ressources.
• Premières suggestions publiées sur les demandes de ressources de base iframe.
• Prise en charge de la prélecture dans les premiers conseils.

Relation avec HTTP2 Push ou H2/Push

Si vous connaissez la fonctionnalité obsolète HTTP/2 Push , vous vous demandez peut-être en quoi les Early Hints diffèrent. Alors que les Early Hints nécessitent un aller-retour pour que le navigateur commence à récupérer les sous-ressources critiques, avec HTTP/2 Push, le serveur pouvait commencer à envoyer les sous-ressources avec la réponse. Aussi surprenant que cela puisse paraître, cela a engendré un inconvénient structurel majeur : avec HTTP/2 Push, il était extrêmement difficile d'éviter d'envoyer des sous-ressources déjà disponibles pour le navigateur. Cet effet de « sur-envoi » a entraîné une utilisation moins efficace de la bande passante réseau, ce qui a considérablement réduit les gains de performance. En définitive, les données de Chrome ont montré que HTTP/2 Push avait un impact négatif net sur les performances web.

Inversement, Early Hints fonctionne mieux dans la pratique car il combine la possibilité d'envoyer une réponse préliminaire avec des suggestions qui laissent le navigateur récupérer ou se connecter à ce dont il a réellement besoin. Bien que Early Hints ne couvre pas tous les cas d'utilisation que HTTP2 / Push pourrait théoriquement traiter, nous pensons que Early Hints est une solution plus pratique pour accélérer la navigation.

Conclusion sur les premiers conseils et les performances Web

Ce que nous répétons toujours et que nous ne nous lasserons pas de répéter, c'est que les performances web sont un processus et non un produit. Penser à activer Early Hints, implémenter CloudFlare et ne pas avoir de cache statique comme Varnish, ne pas avoir un réglage adéquat des pools PHP-FPM, avoir des requêtes lentes sur la base de données, une architecture matérielle sous-alimentée, le manque de compression brotli, le manque de TCP BBR avec 0-RTT, ne mènera qu'à la conviction d'avoir résolu l'un des nombreux problèmes qui doivent être résolus avant d'insérer Early Hints.

Il ne suffit pas d'acheter et de porter les chaussures de course d'Usain Bolt pour battre le record du monde, tout comme il ne suffit pas d'activer Early Hints sur le serveur Web pour avoir un site rapide.

Nous vous rappelons cet article sur les différentes étapes à suivre pour avoir un site rapide.