Au delà du temps de réponse du serveur

Le chargement de votre site Web HTML a rapidement un grand impact sur l’expérience des visiteurs. Après tout, aucun contenu de page ne peut être affiché avant la charge du premier morceau du HTML. C’est pourquoi le Il est temps de premier octet La métrique (TTFB) est importante: il mesure combien de temps après la navigation, le navigateur commence à recevoir la réponse HTML.

La génération du document HTML joue rapidement un grand rôle dans la minimisation des retards TTFB. Mais en fait, il y a beaucoup plus à optimiser cette métrique. Dans cet article, nous allons jeter un œil à ce qui peut provoquer un mauvais TTFB et ce que vous pouvez faire pour le réparer.

Quels composants constituent le temps de la première métrique des octets?

TTFB signifie temps à Premier octet. Mais où mesure-il depuis?

Différents outils le génèrent différemment. Certains ne comptent que le temps passé à envoyer la demande HTTP et à obtenir une réponse, en ignorant tout ce qui doit se produire avant que la ressource puisse être chargée. Cependant, lorsque vous regardez Google Core Web VitalsTTFB commence à partir du temps Lorsque les utilisateurs commencent à naviguer vers une nouvelle page. Cela signifie que TTFB comprend:

• Redirection des originaux,
• Temps passé à se connecter au serveur,
• Redirection de même d’origine, et
• La demande réelle pour le document HTML.

Nous pouvons en voir un exemple demander une visualisation de la cascade.

Le Temps de réponse du serveur Voici seulement 183 millisecondes, soit environ 12% de la métrique TTFB globale. La moitié du temps est plutôt consacrée à une redirection des originaux – une demande HTTP distincte qui renvoie une réponse de redirection avant même de pouvoir faire la demande qui renvoie le code HTML du site Web. Et lorsque nous faisons cette demande, la plupart du temps est consacré à l’établissement de la connexion du serveur.

La connexion à un serveur sur le Web prend généralement trois aller-retour sur le réseau:

1. DNS: Recherche de l’adresse IP du serveur.
2. TCP: Établir une connexion fiable au serveur.
3. TLS: Création d’une connexion cryptée sécurisée.

Ce que la latence du réseau signifie pour le temps de premier octet

Ajoutons tous les aller-retour en réseau dans l’exemple ci-dessus:

• 2 connexions de serveur: 6 aller-retour.
• 2 demandes HTTP: 2 aller-retour.

Cela signifie qu’avant même d’obtenir le premier octet de réponse pour notre page Nous devons en fait envoyer des données entre le navigateur et un serveur huit fois!

C’est là que la latence du réseau entre en jeu, ou temps aller-retour en réseau (RTT) Si nous examinons l’heure qu’il faut pour envoyer des données à un serveur et recevoir une réponse dans le navigateur. Sur une connexion élevée avec un RTT de 150 millisecondes, faire ces huit aller-retour prendra 1,2 seconde. Ainsi, même si le serveur répond toujours instantanément, nous ne pouvons pas obtenir un TTFB inférieur à ce nombre.

La latence du réseau dépend beaucoup des distances géographiques entre le périphérique du visiteur et le serveur auquel le navigateur se connecte. Vous pouvez voir l’impact de cela dans la pratique en gérant un Test mondial de TTFB sur un site Web. Ici, j’ai testé un site Web hébergé au Brésil. Nous obtenons de bons scores TTFB lors des tests du Brésil et de la côte est des États-Unis. Cependant, les visiteurs d’Europe, d’Asie ou d’Australie attendent un peu de temps pour que le site Web se charge.

Ce que les réseaux de livraison de contenu signifient pour le temps de premier octet

Une façon d’accélérer votre site Web est d’utiliser un Réseau de livraison de contenu (CDN). Ces services fournissent un réseau d’emplacements de serveurs distribués à l’échelle mondiale. Au lieu que chaque aller-retour se déroule jusqu’à l’endroit où votre application Web est hébergée, les navigateurs se connectent plutôt à un serveur CDN à proximité (appelé un nœud Edge). Cela réduit considérablement le temps consacré à l’établissement de la connexion du serveur, améliorant votre métrique TTFB globale.

Par défaut, la demande HTML réelle doit toujours être envoyée à votre application Web. Cependant, si votre contenu n’est pas dynamique, vous pouvez également Réponses de cache au nœud CDN Edge. De cette façon, la demande peut être entièrement servie par le CDN au lieu que des données voyagent dans le monde entier.

Si nous exécutons un test TTFB sur un site Web qui utilise un CDN, nous pouvons voir que chaque réponse du serveur provient d’un centre de données régional proche de l’endroit où la demande a été faite. Dans de nombreux cas, nous obtenons un TTFB de moins de 200 millisecondes, grâce à la réponse déjà mise en cache au nœud Edge.

Comment améliorer le temps pour premier octet

Ce que vous devez faire pour améliorer le score TTFB de votre site Web dépend de son plus grand composant contributif.

• Beaucoup de temps est passé à établir la connexion: Utilisez un CDN global.
• La réponse du serveur est lente: Optimisez votre code d’application ou Cache la réponse
• Redirigez le retard TTFB: Évitez les redirectes de chaîne et Optimiser le serveur Retour de la réponse de redirection.

Gardez à l’esprit que le TTFB dépend de la façon dont les visiteurs accédent à votre site Web. Par exemple, s’ils sont connectés à votre application, le contenu de la page ne peut probablement pas être servi à partir du cache. Vous pouvez également voir un pic dans TTFB lors de l’exécution d’une campagne publicitaire, car les visiteurs sont redirigées via un serveur de suivi des clics.

Surveiller le temps réel de l’utilisateur pour premier octet

Si vous souhaitez obtenir une ventilation de ce à quoi ressemble TTFB pour les différents visiteurs de votre site Web, vous avez besoin Surveillance réelle des utilisateurs. De cette façon, vous pouvez décomposer la façon dont l’emplacement des visiteurs, l’état de connexion ou le domaine du référent ont un impact sur une expérience utilisateur réelle.

Debugbear Peut vous aider à collecter de véritables mesures utilisateur pour le temps de premier octet, Google Core Web Vitals et d’autres métriques de vitesse de page. Vous pouvez suivre les composants TTFB individuels comme la durée TCP ou le temps de redirection et décomposer les performances du site Web par pays, campagne publicitaire, etc.

Conclusion

En regardant tout ce qui est impliqué dans le service du premier octet d’un site Web à un visiteur, nous avons vu que la simple réduction du temps de réponse du serveur n’est pas suffisante et ne sera souvent pas le changement le plus percutant que vous puissiez apporter sur votre site Web.

Ce n’est pas parce que votre site Web est rapide dans un seul endroit pour tout le monde, car la vitesse du site Web varie en fonction de l’endroit où le visiteur accéde à votre site.

Réseaux de livraison de contenu sont un moyen incroyablement puissant d’améliorer le TTFB. Même si vous n’utilisez aucune de leurs fonctionnalités avancées, l’utilisation de son réseau de serveurs global permet de gagner beaucoup de temps lors de l’établissement d’une connexion de serveur.

(GG, YK)