Peut-être avez-vous entendu la phrase Temps au premier octet mais de toute façon, le concept semble échapper à certaines personnes. Que ce soit parce que cela semble incroyablement orienté technologie ou parce que cela semble être un concept abstrait, ce n’est pas très important pour une utilisation quotidienne. Rien ne pourrait être plus éloigné de la vérité.
Time to First octet n'est pas réellement un concept ou une idée que seuls les techniciens doivent comprendre. Tout le monde devrait pouvoir comprendre sa signification et l’appliquer dans la pratique.
Dans cet article, je vais vous expliquer en quelques mots: qu'est-ce que Time to First Byte, en quoi cela affecte-t-il votre site et pourquoi devriez-vous accorder une attention particulière à ce sujet? si vous voulez donner à vos lecteurs la meilleure expérience possible lors de la navigation sur votre site.
Quel est le temps au premier octet?
Le temps jusqu'au premier octet (TTFB) est une mesure utilisée comme indication de la réactivité d'un serveur Web ou d'une autre ressource réseau.
TTFB mesure la durée entre le moment où l’utilisateur ou le client émet une requête HTTP et le premier octet de la page reçue par le navigateur du client. Ce temps est composé du temps de connexion du socket, du temps nécessaire pour envoyer la requête HTTP et du temps nécessaire pour obtenir le premier octet de la page. Bien que parfois mal compris comme un calcul post-DNS, le calcul initial de TTFB en réseau inclut toujours le temps de latence du réseau dans la mesure du temps nécessaire au chargement d'une ressource.
C’est l’explication «technique» tirée directement de Wikipedia. Maintenant, traduisons cela en un texte plus simple qui convient à tout le monde.
Time to First est le temps qu'il faut pour que vous appuyiez sur ce bouton pour charger un site Web au moment où il commence le rendu. Si vous deviez parler de cela en termes de jeu, le délai avant octet serait similaire à la «latence» ou au «décalage» que vous avez pendant le jeu. La latence est une représentation directe de la réactivité perçue de votre site.
Quels facteurs affectent le temps au premier octet?
Le temps nécessaire au premier octet peut être représenté par plusieurs facteurs, mais puisqu'il s'agit d'un article WordPress, nous allons tout réduire à ce qui est affecté lorsque WordPress est en place.
- Temps de réponse DNS
- Configuration et performances du serveur (PHP et serveur Web)
- WordPress Plugins / Thème
- Mise en cache HTML activée / désactivée
Chacun de ces facteurs ajoute une latence supplémentaire au temps qu’il faut à votre site pour commencer le rendu. Cela signifie que ça tout s'additionne. Ce n'est pas ça certains de ces facteurs peuvent avoir un impact sur la latence, tout de ces facteurs contribuent à plus de latence! Vous pouvez donc deviner que pour un scénario idéal, tout devrait être rapide pour que vous obteniez un très bon temps jusqu'au premier octet et si quelque chose de cette chaîne prend plus de temps à traiter, votre dernier octet final en souffrira.
C'est important parce que Time to First octet affecte tout ce que vous ou vos lecteurs faites sur votre site. Chaque fois qu'un lecteur cliquera sur un lien, une image, un article de blog ou une page, Time to First Byte sera pris en compte. Vous pouvez voir qu'un mauvais Time to First Byte signifie que le lecteur aura une situation similaire à celle d'un joueur connecté à un serveur de mauvaise qualité. Chaque clic sera associé à un décalage considérable qui aura un impact sur l'expérience.
Remarque: à partir de maintenant, je vais utiliser l’acronyme TTFB pour désigner Time to First Byte, simplement pour accélérer un peu les choses.
1. Temps de réponse DNS
La résolution DNS est le premier facteur de l'équation. Veillez à toujours utiliser de bons serveurs DNS et à ce qu'ils disposent de nœuds répartis dans le monde pour obtenir la meilleure résolution possible. Un bon moyen de réduire les frais de TTFB à cette étape consiste à utiliser un bon service mondial tel que CloudFlare lors de la mise en œuvre de ce type de service. Mise en cache DNS globale. Cette méthode est extrêmement efficace pour réduire TTFB en mettant en cache d'autres résolutions.
2. Configuration du serveur
La deuxième étape de la latence TTFB est le serveur actuel. C'est ici que votre hébergement se met en place. Le type de configuration du serveur Web utilisé et les techniques de mise en cache grandement réduire TTFB. Par exemple, si votre serveur implémente l'ancien interpréteur PHP 5.4, vous obtiendrez un TTFB très élevé, alors que l'utilisation d'une configuration moderne de PHP 7.1 réduira ce temps d'un facteur 2 ou plus.
En effet, l'interpréteur PHP joue un rôle important dans le processus. Chaque fois que vous demandez une page de site Web ou un article de blog qui est non attaché, le serveur devra traiter les fichiers PHP en question pour les convertir au format HTML sur votre navigateur. Plus les fichiers PHP sont complexes, plus il faudra de temps pour les pré-traiter et les renvoyer à votre navigateur.
Vous pouvez voir que les performances du serveur occuperont également une place importante dans l'ensemble du processus. Plus le processeur est rapide et plus votre hébergement vous alloue de ressources, plus il traitera ces fichiers rapidement et, par conséquent, votre TTFB sera plus petit.
De plus, si votre hébergement implémente une mise en cache PHP, celle-ci sera encore réduite à la deuxième requête car elle fournira une version mise en cache de ce fichier au lieu de devoir traiter à nouveau le fichier PHP.
Vous pouvez voir maintenant qu’il existe 2 types d’hébergement, les services généraux (non mis en cache) et les services d’hébergement exclusif WordPress qui implémentent généralement mécanisme de mise en cache pour PHP, réduisant votre TTFB dans le processus.
3. Plugins WordPress et Thème
La troisième étape de l'équation TTFB est votre site actuel. C’est le facteur le plus important et je vais vous expliquer pourquoi.
Habituellement, WordPress donnera à votre hébergement plusieurs fichiers PHP à traiter et plus ils seront complexes, plus le traitement sera long. WordPress est desservi par plugins et ces plugins ajoute du code supplémentaire pour le traitement final de PHP donc avec cela à l'esprit, vous pouvez voir clairement que plus vous avez installé de plugins, plus votre hébergement prendra de temps pour les traiter. et par conséquent, votre TTFB augmentera.
Le moins le mieux
En règle générale, moins de plugins est généralement préférable. Bien sûr, un plugin mal codé peut être bien pire que 10 plugins codés de manière experte ou il est possible d’installer deux plugins qui se trouvent en conflit. Mais en règle générale, la réduction du nombre de plug-ins facilite la gestion des mises à jour et accélère la vitesse de votre site. Voici un exemple d’une quantité raisonnable de plugins pour une installation.
Cet exemple suivant pourrait poser problème (encore une fois – cela dépend en partie de ce que vous avez installé).
Et bien sûr, tout ce qui dépasse les 30 plugins n’est probablement pas bon pour votre latence. Vous pouvez être sûr qu’un site Web avec plus de 40 plugins aura un TTFB très élevé, même s’il est hébergé sur un service d’hébergement spectaculaire, et je vais vous montrer pourquoi.
4. Mise en cache HTML
Le dernier facteur est le plus important et est lié à la mécanisme de mise en cache vous décidez de mettre en œuvre sur votre installation WordPress. Bien qu'il existe plusieurs types de mécanismes de mise en cache dans WordPress, le plus efficace de tous est Mise en cache HTML.
Avoir un bon plugin comme KeyCDN Cache Enabler aura un impact énorme sur votre TTFB, encore plus que l’hébergement lui-même. Il convertira tous ces fichiers en HTML. Ainsi, une fois le cache activé, vos lecteurs n'auront plus besoin de passer par le pré-processeur PHP de votre hébergement. seul le serveur web lui-même responsable de servir votre contenu. Vous pouvez même accélérer le processus encore plus si vous décidez d’utiliser un hébergement qui inclut nginx au lieu d’apache comme serveur Web principal, comme je l’ai expliqué dans cet article.
Time to First Byte Études de cas: Pourquoi est-ce important?
Maintenant, laissez-moi vous montrer de quoi nous parlons. Les études de cas suivantes sont des exemples concrets de configurations de sites Web sur différents serveurs, avec un résumé de référence pratique à la fin.
Un site Web lent sur un serveur lent
Avoir un site lent peut être un problème pour TTFB et si vous ne vous souciez pas d’un bon service d’hébergement, vous devez être prêt à faire face aux pires résultats possibles.
Analysons ce site en détail. Pour ce faire, je vais utiliser Pingdom Tools car c’est un excellent outil pour vous permettre de voir le TTFB. L'astuce consiste à ouvrir le détail sur la première demande faite au site.
Comme vous pouvez le constater, le site dispose d’un TTFB d’au moins 4,2 secondes! Cela signifie 4 secondes complètes jusqu'à ce que vous obteniez une indication de la disponibilité du site Web.
Maintenant, multipliez ce temps par tous les clics que vous allez faire sur le site et vous pouvez voir à quel point cela peut être pénible pour un lecteur. Bien entendu, TTFB doit être ajouté au temps total nécessaire au rendu du site. Le résultat sera catastrophique pour la performance que le site prendra autant que 7 secondes pour rendre correctement parfois.
La combinaison de plusieurs facteurs conduit à cela. Un site Web mal optimisé sans mécanisme de mise en cache, un service d'hébergement très lent et un interpréteur PHP totalement obsolète, qui exécute toujours PHP 5.4. Même lorsque le site utilise cloudflare en tant que mécanisme de mise en cache externe, rien ne peut être fait pour améliorer la situation si votre site et votre hébergement ne coopèrent pas.
Un site Web rapide sur un serveur moyen
Voyons ce qui se passe lorsque nous mettons un site très rapide sur un serveur moyen utilisant Apache et PHP 7.1.
Avec un site contenant moins de 10 plugins sans cache, le résultat est au moins 5 fois meilleur que le précédent. Vous pouvez voir que TTFB est maintenant réglé à 521ms. Cela signifie que le rendu du site sur votre navigateur va prendre 0,5 seconde, à partir du moment où il passe du serveur au moment où il atteint votre ordinateur.
Que se passe-t-il lorsque nous activons le cache sur ce site? La magie arrive. Un serveur généralement moyen fonctionnant sur Apache peut donner d’excellents résultats avec seulement 152 ms de TTFB. Vous pouvez voir à quel point bonne mise en cache WordPress mécanisme affecte les résultats.
Un site Web très lent sur un serveur rapide
Voyons maintenant le contraire. Que se passe-t-il si nous mettons un site très lent sur un serveur très rapide?
Un serveur optimisé exécutant Plesk avec nginx et PHP 7.1.11 mettra 1,29 seconde pour générer un site contenant des plugins (plus de 27).
Mais lorsque nous activons la mise en cache sur WordPress par le biais de KeyCDN Cache Enabler, le résultat est incroyable. Le site très lent a son TTFB réduit à seulement 400ms.
Un site Web rapide sur un serveur rapide
Voyons maintenant la situation optimale. Un site Web rapide fonctionnant sur un serveur rapide.
Le même serveur qui donnait un TTFB de 1,29 seconde sur un site lent répond en moins de 500 ms sur un site rapide sans cache.
Si nous activons le cache, les résultats sont simplement étonnants. Un serveur rapide, combiné à un site Web rapide avec la mise en cache activée, donne moins de 150 ms de TTFB!
Résultats de référence
Voyons les résultats dans un grand graphique pour les amateurs de référence.
Vous pouvez constater que l'hébergement joue un rôle important dans la réduction de votre temps TTFB et dans l'amélioration de la latence et des performances perçues de votre site, mais que ce que vous faites avec le site a le plus d'impact sur les performances.
Emballer
Avoir un bon métrique TTFB vous garantira que vous aurez un site rapide et réactif, cela réduira votre temps de rendu général et servira d’excellent métrique pour déterminer la performance. Généralement, plus le TTFB est élevé, plus votre site sera lent. Il est primordial de garder à l'esprit la fonctionnalité TTFB lors de l'analyse comparative de votre site, car cette synchronisation peut également être utilisée pour déterminer les goulots d'étranglement de votre installation WordPress. Vous pouvez faire un exercice simple en désactivant simplement tous les plugins, en basculant sur un thème de base, puis en mesurant à nouveau TTFB. Vous serez surpris par les résultats.
Je souhaite terminer cet article en affirmant qu'il ne s'agit en aucun cas d'une «mesure permettant de toutes les gouverner», car il existe d'autres facteurs à prendre en compte, notamment les performances de la base de données, la bande passante disponible et la vitesse du réseau. Mais comme TTFB est généralement affecté par tous ces facteurs, c’est une bonne indication des goulets d’étranglement ailleurs.
J'espère que vous saisirez l'occasion d'essayer votre TTFB. Laissez vos commentaires ci-dessous. Nous aimerions entendre parler de vos propres tests ou vous aider à répondre à vos questions.
