Et non, contrairement à ce que la photo laisse entendre, nous n’allons pas vous parler du TTFB gastronomique, le fameux TarTare Frites Béarnaise… Mais du TTFB mesure technique, le non moins célèbre Time To First Byte, traduisible dans la langue de Molière par “Le temps de chargement du premier octet”.
Qu’est-ce que le TTFB ?
Il s’agit de la mesure du temps attendu par le navigateur avant de recevoir son premier octet de donnée provenant du serveur. Et il ne s’agit pas là du premier affichage ou même de l’affichage du premier pixel de la page, mais uniquement du premier bout de code que le navigateur reçoit. Il est donc logique que ce soit quasiment le premier indicateur retourné dans tous les outils de mesure.
Pour bien comprendre de quoi il en retourne, décrivons les différentes étapes.
A partir du moment où vous rentrez une URL, le navigateur va effectuer les opérations suivantes :
- Mise en file d’attente,
le navigateur met la demande dans la file pour une des raisons suivantes :- Il y a des demandes plus prioritaires.
- Il y a déjà six connexions TCP ouvertes pour cette origine, qui est la limite. S’applique uniquement à HTTP/1.0 et HTTP/1.1.
- Le navigateur alloue brièvement de l’espace dans la mémoire cache du disque. Ce qui peut prendre un peu de temps.
- Temps d’attente,
dû à l’une des raisons précédentes. - Recherche DNS,
le navigateur demande à un serveur DNS à quelle IP correspond le nom de domaine de la requête. - Requête envoyée,
la requête est en cours d’envoi. - En attente du traitement par le serveur,
le navigateur attend le premier octet d’une réponse. Ce temps comprend 1 aller-retour de latence et le temps que le serveur a pris pour préparer la réponse. - Téléchargement de contenu,
le navigateur reçoit la réponse.
NB : Et j’ai mis de côté les subtilités liées au proxy, au push HTTP/2, et au service worker…
Donc l’idée dans le TTFB est de mesurer le temps à l’étape 5 afin de déterminer l’efficacité du serveur.
La mesure qui fâche !
Si l’on regarde un rapport Dareboost dans le détail, le premier octet indiqué reprend les étapes 3, 4 et 5 et indique le temps au tout départ de l’étape 6.
Dès lors, il faut bien comprendre que la latence du réseau est prise en compte. Pour être clair la latence correspond au temps de transport des données sur le réseau. Il va donc de soi qu’en fonction du réseau utilisé la mesure diffère. Par exemple, sur ce site, le TTFB mesuré en 3G est d’environ 500 ms, alors qu’il est d’un peu plus de 200 ms en ADSL.
De plus, le temps de transport des données dépend aussi de la distance entre votre point de connexion et la position du serveur. Les valeurs indiquées ci-dessus correspondent à une connexion depuis Paris à un serveur situé en France.
Or la recommandation jusqu’à mai dernier selon Google reprise dans l’annotation de Dareboost précise bien :
Le temps de réponse du serveur est le temps qu’il faut à un serveur pour retourner le HTML initial, sans tenir compte du temps de transport du réseau. Parce que nous n’avons que si peu de temps, ce temps devrait être maintenu à un minimum – idéalement dans les 200 millisecondes, et de préférence même moins !
“Sans tenir compte du temps de transport du réseau” : donc Google recommande 200 ms uniquement pour l’étape 5. La recommandation de Google ne concerne donc qu’un morceau du TTFB.
Quelle recommandation pour le TTFB complet ?
Outre le fait qu’à chaque fois mon amour propre est blessé par le fait de ne pas avoir obtenu la bonne note, on constate que les mesures du TTFB des sites “webperfés” sont situées entre 600 et 400 ms en 3G. Dareboost restera donc toujours au mieux dans le orange.
En effet, durant le temps où les serveurs n’avaient pas de cryptage à assurer entre le navigateur et eux mêmes, on pouvait passer sous la barre des 200 ms en ADSL. Mais aujourd’hui, et c’est une bonne chose, nous sommes passer de l’HTTP au HTTPS ! Et là, passer sous la barre des 200 ms devient rudement plus difficile.
Si vous m’avez suivi jusque là, la recommandation de Google était valable jusqu’à mai dernier ! En farfouillant un peu dans la documentation de l’outil de test référent chez Google, à savoir LightHouse, la “nouvelle” recommandation concernant le test du TTFB est différente :
Cet audit échoue lorsque le navigateur attend plus de 600 ms pour que le serveur réponde à la demande du document principal.
Quand on sait que LightHouse ne teste que des contextes réseau “Slow 4G”, on peut extrapoler une recommandation à 600 ms en 3G. Donc, même si Dareboost vous remonte ce point dans le rouge ou le orange, gardez à l’esprit que sa valeur de référence est de 200 ms quelque soit le contexte. Google recommande désormais un TTFB situé sous les 600 ms en “Slow 4G”. De notre cotés, artwaï interprète qu’être en dessous des 600 ms en 3G est un bon score, alors qu’en ADSL on devrait rester sous les 300 ms.
Mon TTFB est lent que dois-je faire ?
Nous avons vu que le TTFB dépend du temps de recherche DNS, du temps de transport réseau et du temps de traitement coté serveur.
Le temps de recherche DNS
Selon dnsperf.com, en Europe, un bon temps de recherche DNS doit être aux alentours des 20 ms. Au delà de 30 ms, il y a matière à débattre avec votre hébergeur de nom de domaine.
Le temps de transport réseau
Évidemment, vous êtes, dans un premier temps, tributaire du réseau utilisé (3G, 4G, 5G, ADSL, Fibre,etc). A moins d’être un dirigeant d’un grand opérateur, votre levier d’action est quasi-nul. Et même si l’ARCEP ne cesse de challenger les opérateurs sur le déploiement des réseaux que cela soit pour la Fibre ou le taux de couverture, nous devrons toujours prendre en compte dans nos mesures un réseau de qualité moyenne. Pour ma part, je préfère tester en 3G car nous avons un historique de mesures qui nous permet leurs comparaisons.
Ensuite nous pouvons raccourcir les distances entre l’utilisateur et le serveur. Alors non, cela ne va pas vous coûter une fortune en taxi ! Vous pouvez utilisez un CDN (Content Delivery Network ou RDC, Réseau de Diffusion de Contenu en français), il sert d’intermédiaire entre votre site et l’internaute. En effet, le CDN est un réseau de serveurs répartis dans différentes localisations qui va répondre aux utilisateurs les plus proches. Il y a un inconvénient : cette solution ne va pouvoir traiter que des ressources statiques et non pas des pages dynamiques. De plus, il faut rafraîchir régulièrement les données sur le CDN en fonction de vos contenus.
Le temps de traitement coté serveur
Pour cette mesure, il y a énormément de paramètres qui rentrent en compte ! Il faut déjà analyser votre infrastructure matérielle : serveur mutualisé, serveur dédié, cloud scalable… Les performances intrinsèques du ou des disques durs, de la RAM et de la puissance de calcul ont un impact direct sur les temps de traitements. Il ne faut pas oublier que bien souvent votre site web repose sur une base de données. Celle-ci aussi a des caractéristiques qui impactent les performances. Dans un premier temps, il faut s’assurer de leurs bonnes configurations et des mises à jour qui, bien souvent, améliorent les performances.
De même, les langages dynamiques utilisés pour votre site sont en cause. Par exemple, comme on vous l’a déjà prescrit, nous recommandons fortement de passer à Php 7 au lieu de rester à Php 5. Pourtant, encore aujourd’hui, le Php 5 est plus utilisé que Php 7…
De plus, surtout dans le cadre d’un serveur mutualisé, il se peut que votre serveur soit occupé à faire autre chose que répondre à vos internautes. Pourquoi ? Quand ? Combien de temps ? Autant de questions qu’un administrateur serveur devrait analyser pour y répondre et vous aider à faire vos choix.
Le serveur de cache… misère !
Enfin, il reste une solution qui est bien trop souvent un cache-misère : un serveur de cache. Puisque que vos pages prennent du temps à être générées, pourquoi ne pas les générer à l’avance pour n’avoir qu’à les envoyer quand les utilisateurs les demandent ? Dans certains cas, on peut même cumuler un système de cache et un CDN. Alors oui, si un serveur de cache de type Varnish est très efficace (avec un contenu statique ne l’oublions pas), cela ne permet pas de traiter les vrais problèmes de lenteurs coté serveur. Cela revient à mettre la poussière sous le tapis. Si vos traitements sont déjà bien optimisés le serveur de cache est une arme en plus. Sinon cela risque d’aboutir à des problèmes d’engorgements à terme, provoquant moult erreurs si les lenteurs s’accumulent !
Conclusion
L’amélioration du TTFB peut donc être complexe, surtout concernant le temps de traitement coté serveur. Au delà de la web performance, solutionner ces problèmes peuvent avoir 2 impacts non négligeables :
- Les solutions d’hébergement deviennent de plus en plus facturées à l’usage : plus vous sollicitez les ressources sur le serveur, plus cher vous paierez… D’un point vue économique il est donc intéressant d’optimiser ces temps de traitements coté serveur !
- Et donc moins vous sollicitez le serveur moins il nécessite d’énergie pour fonctionner. C’est donc la base de l’écoconception. Vous participez ainsi à une sobriété heureuse plutôt bénéfique pour notre environnement (et çà, à Langouët, on y est sensible !).
Un point de vigilance pour terminer : malgré mon historique personnel, surtout n’improvisez pas ! La mise en place de ces systèmes sont suffisamment compliqués et multifactoriels pour éviter de se lancer tout seul. Fiez vous à des spécialistes pour vous accompagner, le cas échéant vous connaissez une agence web rennaise que vous pouvez contacter.
Merci à Damien Jubeau de Dareboost pour avoir corriger une traduction approximative d’une recommandation de Google.
Photo réalisée par mes soins,
en hommage aux déjeuners quasi-rituels composés exclusivement de TTFS,
pris régulièrement avec mes 2 associés il y a bientôt 14 ans, lors de la création d’artwaï.
