Quel est le temps de premier octet et comment l’améliorer sur votre site WordPress

Vous avez peut-être entendu la phrase Temps jusqu’au premier octet mais en quelque sorte le concept semble échapper à certaines personnes. Que ce soit parce qu’il semble incroyablement orienté vers la technologie ou parce qu’il semble être un concept abstrait, pas si important pour un usage quotidien. Rien ne pouvait être plus loin de la vérité.


Time to First byte n’est pas en fait un concept ou une idée que seuls les techniciens doivent comprendre. Tout le monde devrait pouvoir saisir son sens et l’appliquer dans la pratique.

Dans cet article, je vais vous expliquer en quelques mots: qu’est-ce que Time to First Byte, comment cela affecte-t-il votre site et pourquoi vous devriez accorder une attention considérable à ce sujet si vous souhaitez offrir à vos lecteurs la meilleure expérience possible lors de la navigation sur votre site.

Quel est le temps pour le premier octet?

Le temps jusqu’au premier octet (TTFB) est une mesure utilisée comme une indication de la réactivité d’un serveur Web ou d’une autre ressource réseau.

TTFB mesure la durée entre l’utilisateur ou le client effectuant 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 en tant que calcul post-DNS, le calcul d’origine du TTFB dans les réseaux inclut toujours la latence du réseau pour mesurer le temps nécessaire à une ressource pour commencer le chargement.

C’est l’explication «technophile» tirée directement de Wikipédia. Maintenant, traduisons cela en un texte plus simple qui sert tout le monde.

Time to First byte est le temps qu’il vous faut pour appuyer sur ce bouton pour charger un site Web au moment où il commence à s’afficher. Si vous parliez de cela en termes de jeu, le délai jusqu’au premier octet serait similaire à la «latence» ou au «décalage» que vous avez en jouant. La latence est une représentation directe de la réactivité perçue de votre site.

Quels facteurs affectent le temps de premier octet?

Le temps de premier octet peut être représenté par plusieurs facteurs, mais comme 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)
  • Plugins / Thème WordPress
  • Mise en cache HTML activée / désactivée

Chacun de ces facteurs ajoute une latence supplémentaire au temps nécessaire à votre site pour commencer le rendu. Cela signifie qu’il 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! Donc, vous pouvez deviner que pour un scénario idéal, tout devrait être rapide pour que vous obteniez un très bon Time to First Byte et si quelque chose dans cette chaîne prend plus de temps à traiter, votre dernier Time to First byte en souffrira..

Ceci est important car Time to First byte affecte tout ce que vous ou vos lecteurs faites sur votre site. Chaque fois qu’un lecteur clique sur un lien, une image, un article de blog ou une page, le délai jusqu’au premier octet sera pris en considération. Vous pouvez voir qu’un mauvais Time to First Byte signifie que le lecteur aura une situation similaire à un joueur connecté à un serveur médiocre. Chaque clic aura un décalage considérable associé et cela aura un impact sur l’expérience.

Remarque: à partir de maintenant, je vais utiliser l’acronyme TTFB pour désigner le temps jusqu’au premier octet juste 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. Assurez-vous toujours d’utiliser de bons serveurs DNS et de disposer de nœuds répartis dans le monde pour obtenir la meilleure résolution possible. Une bonne façon de réduire le TTFB dans cette étape consiste à utiliser un bon service global comme CloudFlare comme ce genre de service met en œuvre Mise en cache DNS globale. Cette méthode est extrêmement bonne pour réduire le TTFB en mettant en cache d’autres résolutions.

2. Configuration du serveur

La deuxième étape de la latence TTFB est le serveur réel. C’est là que votre hébergement prend place. Le type de configuration de serveur Web qu’il utilise et les techniques de mise en cache réduire considérablement 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 PHP 7.1 moderne 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 non mis en cache, le serveur devra traiter les fichiers PHP en question pour les reconvertir au format HTML dans 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 prendront également une part importante sur l’ensemble du processus. Plus le processeur est rapide et plus votre hébergement vous alloue de ressources, plus il traitera rapidement ces fichiers et, par conséquent, votre TTFB sera plus petit.

De plus, si votre hébergement implémente une mise en cache PHP, cela sera encore réduit à la deuxième demande car il fournira une version en cache de ce fichier au lieu d’avoir à traiter le fichier PHP à nouveau.

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 exclusifs WordPress qui implémentent généralement un mécanisme de mise en cache pour PHP, réduire votre TTFB dans le processus.

3. Plugins et thème WordPress

La troisième étape de l’équation TTFB est votre site réel. C’est le facteur le plus important et je vais vous montrer pourquoi.

Habituellement, WordPress donnera à votre hébergement plusieurs fichiers PHP à traiter et plus ils sont complexes, plus le temps de traitement sera long. WordPress est desservi par plugins et ces plugins ajoute du code supplémentaire au traitement PHP final donc dans cet esprit, vous pouvez clairement voir que plus vous avez installé de plugins, plus il faudra de temps à votre hébergement pour les traiter et donc, votre TTFB augmentera.

Moins c’est mieux

En règle générale, moins de plugins est généralement mieux. Bien sûr, un plugin mal codé peut être bien pire que 10 plugins codés par des experts ou il est possible d’installer deux plugins qui se produisent en conflit. Mais d’une manière générale, la réduction du nombre de plugins vous permet de gérer plus facilement les mises à jour et accélère la vitesse de votre site. Voici un exemple d’une quantité raisonnable de plugins pour une installation.

Temps pour le premier octet: moins de plugins

Cet exemple suivant pourrait être problématique (encore une fois – cela dépend en partie de ce que vous avez installé).

Time to First Byte: plus de plugins

Et bien sûr, tout ce qui dépasse la barrière des 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 il est lié à la mécanisme de mise en cache vous décidez de l’implémenter 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 Activateur de cache KeyCDN aura un impact énorme sur votre TTFB, encore plus que sur l’hébergement lui-même. Il convertira tous ces fichiers en HTML, donc une fois le cache actif, vos lecteurs n’auront pas besoin de passer par le pré-processeur PHP de votre hébergement et il sera seul le serveur web lui-même responsable de la diffusion de votre contenu. Vous pouvez même accélérer encore plus le processus si vous décidez d’utiliser un hébergement qui comprend nginx au lieu d’Apache en tant que serveur Web principal, comme je l’ai expliqué dans cet article.

Temps pour les études de cas du premier octet: pourquoi c’est 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 divers 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 pénible pour TTFB et si vous ne vous souciez pas d’un bon service d’hébergement, vous devez être prêt à faire face au pire résultat possible.

Temps de premier octet: site lent, performances du serveur lentes

Analysons ce site en détail. À cet effet, je vais utiliser les outils Pingdom car c’est un excellent outil pour vous permettre de voir le TTFB. L’astuce consiste à ouvrir le détail à la première demande faite au site.

Temps de premier octet: site lent, réponse lente du serveur

Comme vous pouvez le constater, le site dispose d’un TTFB d’au moins 4,2 secondes! Cela signifie que 4 secondes complètes s’écoulent jusqu’à ce que vous obteniez une indication que le site Web est réellement disponible.

Maintenant, multipliez ce temps par tous les clics que vous allez faire sur le site et vous pouvez voir combien cela pourrait être douloureux pour un lecteur. Bien sûr, TTFB doit être ajouté au temps total nécessaire au rendu du site. Le résultat sera catastrophique pour les performances car le site prendra autant 7 secondes pour rendre correctement parfois.

La combinaison de plusieurs facteurs y conduit. 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 complètement obsolète, qui exécute toujours PHP 5.4. Même lorsque le site utilise cloudflare comme mécanisme de mise en cache externe, rien ne pourrait ê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 qui utilise Apache et PHP 7.1

Temps de premier octet: site rapide, réponse moyenne du serveur

Avec un site qui contient 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é à 521 ms. Cela signifie que le site prendra 0,5 seconde pour démarrer le rendu sur votre navigateur, à partir du moment où il passe du serveur au moment où il atteint votre ordinateur..

Temps de premier octet: site rapide, réponse moyenne du serveur 2

Que se passe-t-il lorsque nous activons le cache sur ce site Web? La magie opère. Un serveur généralement moyen fonctionnant sur Apache peut donner d’excellents résultats avec seulement 152 ms de TTFB. Vous pouvez voir combien 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.

Temps de premier octet: site lent, réponse rapide du serveur

Un serveur optimisé exécutant Plesk avec nginx et PHP 7.1.11 prendra 1,29 secondes pour rendre un site rempli de plugins (plus de 27).

Temps de premier octet: site lent, réponse rapide du serveur 2

Mais lorsque nous activons la mise en cache sur WordPress via le charmant KeyCDN Cache Enabler, le résultat est incroyable. Le site très lent a son TTFB réduit à seulement 400 ms.

Un site Web rapide sur un serveur rapide

Voyons maintenant la situation optimale. Un site Web rapide fonctionnant sur un serveur rapide.

Temps pour le premier octet: Site rapide, réponse rapide du serveur

Le même serveur qui donnait un TTFB de 1,29 secondes sur un site lent répond en moins de 500 ms sur un site rapide sans cache.

Temps pour le premier octet: Fast Site, Fast Server Response 2

Si nous activons le cache, les résultats sont tout simplement incroyables. Un serveur rapide, combiné à un site Web rapide avec 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 benchmarks.

Temps de référence du premier octet

Vous pouvez voir que l’hébergement joue un rôle important dans la réduction de votre TTFB et l’amélioration de la latence et des performances perçues de votre site, mais ce que vous faites avec le site a le plus d’impact sur les performances.

Emballer

Avoir une bonne 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’excellente métrique pour déterminer les performances. Habituellement, plus le TTFB est élevé, plus votre site sera lent. Il est primordial de garder TTFB à l’esprit lorsque vous comparez votre site, car ce moment peut également être utilisé pour déterminer les goulots d’étranglement sur votre installation WordPress. Vous pouvez faire un exercice simple en désactivant simplement tous les plugins et en basculant vers un thème de base, puis en mesurant à nouveau le TTFB. Vous serez étonné par les résultats.

Je veux terminer cet article en disant que ce n’est en aucun cas la «seule mesure pour les gouverner tous» car il existe d’autres facteurs à considérer, notamment les performances de la base de données, la bande passante disponible et la vitesse du réseau. Mais comme le TTFB est généralement affecté par tous ces facteurs également, c’est une bonne indication des goulots d’étranglement ailleurs.

J’espère que vous prendrez une chance d’expérimenter avec votre TTFB. Laissez vos commentaires ci-dessous. Nous aimerions connaître vos propres tests ou répondre à toutes vos questions..

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map