Table des matières de l'article :
Le sujet de cet article est né à la perfection, après plusieurs semaines de "manque d'inspiration" sur des sujets liés à la performance web. Soit parce que le Black Friday a absorbé les énergies pour la mise à l'échelle du e-commerce client, soit parce que nous mettons beaucoup de viande sur le feu avec le développement de plugins pour Prestashop et Magento, ainsi que notre solution CDN dédiée pour les images adaptatives, mais surtout parce que nous avons beaucoup parlé des technologies à l'œuvre et utilisées dans notre pile logicielle spécifique pour WordPress.
Quiconque a lu et suivi les articles et posts publiés au fil du temps a certainement remarqué à quel point il y a des récurrences régulières sur les articles techniques lorsqu'il s'agit d'hébergement WordPress ou d'hébergement Linux d'une manière plus générale.
On finit toujours par parler de NGINX et de Varnish comme du combo ultime en matière de performances et de vitesse, oubliant souvent l'importance d'un réglage minutieux pour obtenir des valeurs adéquates telles que le meilleur TTFB possible.
Nous avons parlé longtemps l'importance d'un TTFB aussi faible que possible, et à quel point il est important d'obtenir une faible latence ; cependant, nous n'avons jamais été en mesure de documenter avec une analyse différentielle deux sites identiques avec la même pile et une optimisation supplémentaire de la pile logicielle et un réglage spécifique pour le serveur Web NGINX.
Le cas particulier né par hasard.
Hier soir, nous avons publié un message sur le mur Facebook privé où le TTFB a été mesuré à l'aide de l'utilitaire SpeedVitals.com, un service en ligne qui vous permet de mesurer le TTFB à partir de plusieurs emplacements dans le monde.
De ce qui était au départ un post "stérile", écrit un dimanche maussade et sans trop d'objectifs, autres que d'extérioriser un petit Vanity Metrics et de nous "rendre beaux", plusieurs commentaires en sont ressortis jusque tard dans la soirée au cours desquels ils étaient nombreux ont répondu en publiant leurs notes et les évaluations que cet outil en ligne a renvoyées.
Parmi les 26 commentaires que vous pouvez voir en bas à droite de l'image ci-dessus, nous avons été particulièrement frappés par le commentaire d'un de nos clients qui a montré un TTFB particulièrement élevé par rapport à celui affiché dans l'écran ci-dessus.
En particulier, il a été souligné que l'évaluation renvoyée était de grade B et que le temps de balayage des araignées de Google n'était pas exactement très faible, atteignant 141 ms.
Considérant que la pile logicielle sous-jacente était pratiquement la même, il fallait certainement aller revoir quelles étaient les problématiques spécifiques des configurations des services Varnish et NGINX pour essayer de tout améliorer et optimiser au mieux.
Analyse des métriques du site en question.
Par chance, le problème soulevé était sous notre contrôle total et donc, même si dimanche, nous voulions entrer dans un "travail de dossier" conscient que cela aurait été une occasion tentante et irremplaçable de montrer et de démontrer comment un réglage super fin aurait pu apporter des bénéfices tangibles et finir par tout documenter avec ce post qui n'est rien de plus qu'une analyse différentielle entre la situation pré et post réglage.
Nous avons donc décidé d'utiliser un utilitaire appelé ByteCheck (bytecheck.com) qui nous permet de mesurer le temps jusqu'au premier octet et décomposer le temps total en différentes étapes qui composent le TTFB total.
À partir de la résolution DNS, au temps de connexion, au temps d'établissement de la connexion cryptée, jusqu'aux temps d'attente et de livraison du contenu, comme on peut le voir dans l'image suivante, dans laquelle il est évident de manière assez évidente et façon incontestable qu'il y a un temps d'attente particulièrement élevé de 240ms.
Objectivement, on se demande ce que fait le serveur Web (ou l'ensemble de la pile) pendant ces 240 ms, un temps trop faible pour supposer que le cache statique Varnish ne fonctionne pas correctement, et en même temps, une valeur trop élevée pour supposer que la pile logicielle est fonctionner normalement du mieux possible.
Nous avons donc voulu tester que le cache statique fonctionnait correctement, en utilisant l'utilitaire Linux CURL, et en examinant la réponse des en-têtes HTTP.
[root@lawebstar ~]# curl -I https://www.ilmiocaneleggenda.it HTTP/1.1 200 OK Serveur : nginx Date : lundi 28 novembre 2022 00:26:46 GMT Type de contenu : text/html ; charset=UTF-8 Connexion : keep-alive Vary : Accept-Encoding Vary : Accept-Encoding Strict-Transport-Security : max-age=86400 ; includeSubDomains X-Content-Type-Options : nosniff X-Frame-Options : DENY X-XSS-Protection : 1 ; mode=bloc Liens : ; rel=précharge ; as=script Liens : ; rel=précharge ; as=script Liens : ; rel=précharge ; as=script Liens : ; rel=précharge ; as=script Liens : ; rel=précharge ; as=script Liens : ; rel="https://api.w.org/" Referrer-Policy : no-referrer-when-downgrade X-Cacheable : OUI X-Varnish : 2.2.0 12 Âge : 2 Via : 32853419 vernis X-Cache : HIT
La réponse en question ne laissait aucun doute sur le fait que le Varnish Static Cache fonctionnait correctement, ayant mis en cache la réponse pendant 4656 secondes et que le cache statique renvoyait un HIT et non un MISS et donc a trouvé (et livré) la réponse déjà stockée dans le cache.
Le problème devait donc se situer en amont, selon la logique "sandwich" dans laquelle NGINX est à la fois le serveur web sur lequel tourne le site web, et le terminateur proxy inverse de la connexion HTTPS, étant donné que Varnish ne supporte pas HTTPS et a besoin de un terminateur HTTPS selon le schéma suivant.
Nous avons donc complètement révisé la configuration de NGINX à la fois globalement et pour les hôtes virtuels individuels, et en ajustant méticuleusement des paramètres tels que les tampons, ainsi qu'en activant certaines fonctionnalités bien documentées dans les dernières versions de NGINX à partir de la 1.22, nous avons obtenu un résultat résolument optimal. évaluer. portant le temps d'attente de 247ms à 124ms, ou en réduisant de moitié le TTFB final.
Évidemment, en tant qu'hébergeur, nous nous excusons à l'avance si nous ne montrons pas les fichiers de configuration spécifiques et ne documentons pas les modifications apportées en détail, étant en fait un savoir-faire que nous avons tendance à ne pas divulguer pour des raisons commerciales évidentes.
L'importance d'un faible TTFB et les avantages que vous retirerez de ce réglage.
Nous avons déjà parlé de l'importance du TTFB comme nous l'avons initialement mentionné dans cet article : Qu'est-ce que le TTFB ? Comment améliorer le Time To First Byte, cependant il est bon de souligner comment Google avec ses paramètres Vitaux Web de base, a décrété qu'un TTFB inférieur à 200 ms peut être considéré comme bon, et un TTFB supérieur qui doit être amélioré.
Quelqu'un pourrait objecter ou se demander quels sont les réels avantages d'un TTFB conforme aux attentes de Google, et s'il est vraiment si important d'avoir un TTFB inférieur à 200ms.
Ce qui est certain, et auquel il faudra faire très attention, c'est que la fréquence de scan des spiders de Google et du TTFB sont directement liés.
Vous pouvez le voir à partir d'un historique comme ci-dessus de la Search Console.
Vous pouvez comprendre à partir des deux lignes bleues et oranges, qu'à mesure que le temps de réponse augmente, (ligne orange TTFB), les requêtes de crawl de Google diminuent (ligne bleue).
À l'inverse, à mesure que le temps de réponse TTFB diminue, les demandes d'exploration de Google augmentent.
Si vous cherchez à connaître les statistiques de crawl de Google, dans la Search Console, allez dans "Paramètres" en bas de la colonne de gauche. Dans la section Analyse, vous trouverez le bouton "Ouvrir le rapport" pour les statistiques d'analyse. Lorsque le rapport est ouvert, vous pouvez cocher la case « Temps de réponse moyen (ms) » pour ajouter la métrique au graphique.
Google utilise 200 ms comme valeur limite dans d'autres tests et rapports, avant d'afficher un avertissement indiquant que le temps de réponse est élevé. Le temps de réponse varie en fonction de votre hébergement, de la qualité du site et de la configuration générale de cache, CDN, ed dans ce cas, le réglage du serveur Web.
Conclusions et observations
A partir de ce cas réel et bien documenté, on peut observer comment l'utilisation des bons outils peut ne pas être suffisante pour obtenir les meilleurs résultats, qui peuvent au contraire être obtenus en utilisant les bons outils, mais aussi et surtout en utilisant les bonnes configurations .
Il est également utile de comprendre comment les bonnes configurations d'il y a des mois ou des années peuvent soudainement ne plus être jugées adéquates ou même dépassées par de nouvelles métriques et de nouvelles exigences qui nécessitent un cycle continu d'adaptations aux nouvelles exigences.
Nous garderons cette étude de cas sous observation pour évaluer également en termes d'indexation avec l'utilitaire SeoZoom, comment cette optimisation a pu impacter le positionnement et l'indexation, évaluer le graphique avant et après le 28 novembre, date à laquelle nous avons travaillé pour améliorer la réponse de les deux sites en question sur le même serveur (ilmiocaneleggenda.it et ilmiogattoeleggenda.it) et évaluant respectivement la tendance des deux sites dans une future analyse différentielle.
