17 mai 2023

Google Crawl Stats et TTFB : une relation très sous-estimée

Vous êtes-vous déjà demandé à quelle vitesse Google Bots récupère le contenu de votre site Web ?

google-crawl-statistiques

L'un des aspects clés pour la visibilité de votre site web concerne l'interaction avec les crawlers de Google, les bots qui scannent votre contenu pour l'indexer dans les résultats de recherche. Deux éléments clés de cette interaction sont les "Crawl Statistics" de Google et le "Time to First Byte" (TTFB). Ces deux facteurs peuvent avoir un impact significatif sur la fréquence à laquelle Google visite votre site et la rapidité avec laquelle votre contenu est indexé.

Google Crawl Statistics est un ensemble de données qui décrit comment les robots d'exploration de Google interagissent avec votre site. Ces données peuvent inclure le nombre de requêtes d'exploration effectuées, le temps qu'il a fallu pour télécharger une page, le succès ou l'échec des requêtes, etc. En général, votre objectif devrait être d'avoir un temps de crawl aussi bas que possible. Un temps d'exploration inférieur signifie que les bots Google peuvent explorer plus de pages en moins de temps, ce qui peut augmenter la fréquence d'indexation de votre site.

Le temps jusqu'au premier octet (TTFB) est une autre mesure clé dans le monde du référencement, nous en avons longuement parlé dans ce post. Il s'agit du temps entre le moment où un client (tel qu'un navigateur Web ou un robot d'exploration Google) effectue une requête HTTP et le moment où il reçoit le premier octet de données du serveur. Encore une fois, un TTFB inférieur est généralement meilleur - cela signifie que les données sont transmises plus rapidement, ce qui peut améliorer à la fois l'expérience utilisateur et l'efficacité de l'exploration de Google.

Une croyance commune est que les Google Bots qui explorent votre site proviennent de centres de données européens, cependant, un examen plus approfondi révèle une réalité différente. En regardant les fichiers access.log de votre serveur Web, il est possible de géolocaliser les IP des crawlers et de découvrir que beaucoup d'entre eux viennent des États-Unis, notamment de Mountain View en Californie. Cela ajoute une latence supplémentaire d'environ 100 ms, comme on peut le voir en cinglant l'IP.

Par exemple, considérons cette IP Google Bot 66.249.64.239 que nous avons récupérée à partir d'un fichier journal récent :

66.249.64.239 - - [14/May/2023:03:37:25 +0200] "GET /wp-includes/js/jquery/jquery.min.js HTTP/2.0" 200 31017 "https://www.ilcorrieredellacitta .com/news" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, comme Gecko ; compatible ; Googlebot/2.1 ; +http://www.google.com/bot.html) Chrome/113.0.5672.63 Safari/537.36"

La plupart d'entre vous savent probablement que Google se trouve à Mountain View et en ont entendu parler des milliers de fois, mais peu savent où se trouve Mountain View géographiquement.

Mountain View est une ville située dans la région de la Silicon Valley du comté de Santa Clara dans l'État de Californie aux États-Unis d'Amérique. Situé sur la côte ouest du continent américain, Mountain View surplombe l'océan Pacifique. Sa position géographique est diamétralement opposée à l'Europe : si l'on considère le trajet d'est en ouest, l'Europe est de l'autre côté de l'océan Atlantique, à des milliers de kilomètres. Cette distance est amplifiée par la présence du continent américain entre les deux points.

Distance-Montagne-Vue-Europe

La distance implique évidemment un temps à parcourir et même si l'on voulait prendre la fibre optique comme moyen de propagation qui a une vitesse proche de celle de la lumière (mais pas celle de la lumière), les temps des différents équipements du réseau doivent nécessairement être ajoutés, tels que les routeurs et le commutateur des différents HOP selon le traceroute suivant par exemple.


Essayons maintenant comme test supplémentaire de pinger l'IP 66.249.64.239 pour mesurer le temps de latence inverse, c'est-à-dire du serveur web au bot Google.

Latence-Google-Bot

On voit bien une latence de 104ms, et à titre indicatif par rapport à une section européenne performante qui ping en 20ms maximum, on a un "plus" d'environ 80ms.
Cette latence peut sembler faible, mais elle s'additionne certainement, et au fil du temps, surtout si votre site comporte de nombreuses pages ou est fréquemment visité par des robots.

Une conséquence directe des temps de crawl plus élevés est une diminution visible des demandes de crawl de Google. Cela est dû à une limitation connue sous le nom de "budget de crawl", qui correspond au nombre de pages que Google peut et va explorer sur une période de temps donnée. Si votre site met trop de temps à répondre aux requêtes des robots d'exploration, Google peut décider de limiter le nombre de pages qu'il explore, ce qui pourrait à son tour réduire la visibilité de votre site dans les résultats de recherche.

Voyons par exemple un reportage d'un de nos anciens clients qui a récemment migré son site vers un hébergeur performant bien connu (du moins ils le disent), notant ce que cela impliquait concrètement.

Il est évident et extrêmement évident que suite au changement de fournisseur, la ligne orange du temps de réponse moyen s'est littéralement envolée, passant d'une bonne valeur de 160 millisecondes à un bon 663 millisecondes, soit plus de 4 fois moins vite. En d'autres termes, si vous voulez compter le serviteur, les bots de Google mettent 4 fois plus de temps à récupérer le contenu du site qu'auparavant.

En fait, si nous voyons le nombre total de demandes d'analyse avant la migration et après la migration, nous remarquons qu'elles sont passées d'environ 30 10 à seulement XNUMX XNUMX., avec une perte d'environ 2/3, une valeur extrêmement inquiétante notamment sur les sites éditoriaux qui ont tendance à produire beaucoup de contenu chaque jour.

En répétant l'analyse des statistiques d'analyse de Google, après environ 20 jours, nous constatons que le temps de réponse moyen est passé des 160 ms optimaux aux 1550 actuels, avec des pics de plus de 300 millisecondes, avec une aggravation de la vitesse d'analyse de 10 à 20 fois.

Les demandes de scan se sont évidemment encore aggravées, passant d'environ 30 5000 à seulement XNUMX XNUMX, décrétant de fait la mort du site sur les moteurs de recherche, Google News et Discovery.

En ce qui concerne le TTFB des moteurs de recherche, on peut trouver un témoignage éloquent à travers l'outil SpeedVitals qui rapporte les métriques suivantes pour ce qui concerne les valeurs européennes :

Valeurs SpeedVitals TTFB

 

Malgré l'importance de ces mesures, de nombreux propriétaires de sites et ingénieurs ne sont pas pleinement conscients de leur impact. Certains peuvent ne pas savoir ce que sont les statistiques de crawl de Google, tandis que d'autres peuvent ne pas comprendre la relation entre le TTFB et le taux de crawl. Ce manque de sensibilisation peut conduire à des décisions sous-optimales concernant l'hébergement du site, la structure du site et l'optimisation des moteurs de recherche, ainsi que la capacité d'évaluer correctement un fournisseur d'hébergement comme nous qui apparaît à un profane ou à un expert autoproclamé "vend de l'hébergement comme tout le monde ".

Par exemple, un propriétaire de site pourrait choisir un hébergeur en se basant principalement sur le prix, ou sur des promesses commerciales hallucinantes et des gains sensationnels, sans tenir compte du fait qu'au-delà du marketing et des belles promesses, ce sont les faits qui qualifient la bonté d'un prestataire, ainsi que des serveurs plus lents ou plus distants peuvent augmenter le TTFB et donc réduire l'efficacité des crawls de Google. De même, une technologie peut se concentrer sur des éléments tels que la sélection de mots clés ou la conception de sites, ignorant le fait qu'une structure de site complexe ou un code inefficace peut augmenter le temps d'exploration et réduire le budget d'exploration, faisant même les meilleures intentions.

Les statistiques d'exploration de Google et le TTFB sont deux facteurs critiques qui peuvent grandement affecter la visibilité de votre site dans les résultats de recherche. Pour optimiser l'interaction de votre site avec les robots d'exploration de Google, il est essentiel de comprendre ces mesures et de les prendre en compte dans toutes les décisions concernant votre site. Cela peut inclure le choix d'un fournisseur d'hébergement approprié comme le nôtre, l'optimisation de votre pile logicielle côté serveur et la surveillance constante de vos statistiques d'exploration et de votre TTFB.

Rapport de statistiques d'analyse

Services CDN comme solution ou palliatif au problème.

Au moins théoriquement, l'une des stratégies les plus efficaces pour améliorer le temps d'analyse est la mise en œuvre d'une pile logicielle robuste, y compris un système de mise en cache côté serveur correctement configuré avec un ratio HIT aussi élevé que possible.

Cependant, même avec la meilleure configuration côté serveur, effectuer des opérations telles que l'accélération de la prise de contact de la session SSL, l'activation de l'agrafage OCSP, TCP BBR et TCP Fast Open, le réglage minutieux du noyau (comme nous le faisons habituellement dans Managed Server Srl) nous sommes inévitablement confrontés à la limite imposée par la distance physique. Cela est particulièrement vrai pour les sites hébergés en Europe qui doivent interagir avec les robots d'exploration de Google basés à Mountain View, en Californie.

Pour surmonter ce défi, de nombreux professionnels de l'industrie se tournent vers les services de réseau de diffusion de contenu (CDN) en mode plate-forme en tant que service (PaaS). Ces solutions offrent la possibilité d'avoir des copies en cache du contenu du site sur des nœuds plus proches de Mountain View grâce à l'utilisation du routage AnyCast.

Un CDN est un réseau de serveurs répartis géographiquement qui fonctionnent ensemble pour diffuser rapidement du contenu Web. Ces serveurs, connus sous le nom de points de présence (POP), stockent des copies du contenu du site Web. Lorsqu'un utilisateur ou un bot demande l'accès à ce contenu, la demande est envoyée au POP le plus proche, réduisant ainsi le temps nécessaire à la transmission des données.

L'origine, dans le contexte d'un CDN, est le serveur ou le groupe de serveurs d'où provient le contenu original. Ces serveurs d'origine livrent le contenu aux POP du CDN, qui le distribuent à leur tour aux utilisateurs finaux.

Le routage AnyCast est une méthode de routage du trafic réseau dans laquelle les demandes d'un utilisateur sont acheminées vers le nœud le plus proche en termes de temps de réponse. Cela peut aider à réduire considérablement le TTFB puisque les données n'ont pas à parcourir de longues distances avant d'atteindre l'utilisateur ou le bot.

Dans le cadre des réseaux informatiques, Anycast est une méthode de routage du trafic réseau qui permet à plusieurs appareils de partager la même adresse IP. Cette méthode de routage est particulièrement populaire dans les services de réseau de diffusion de contenu (CDN) et les systèmes de noms de domaine (DNS), car elle permet de réduire la latence et d'améliorer la puissance du réseau.

Pour comprendre le fonctionnement du routage Anycast, imaginez un réseau de serveurs répartis dans différentes zones géographiques à travers le monde. Chacun de ces serveurs partage la même adresse IP publique. Lorsqu'un utilisateur envoie une demande à cette adresse IP, la demande est acheminée vers le serveur "le plus proche" de cet utilisateur. Ici, le terme "le plus proche" ne fait pas nécessairement référence à la distance physique, mais plutôt à la distance en termes de sauts de réseau ou au temps de réponse le plus court. En pratique, cela signifie que l'utilisateur se connectera au nœud qui pourra répondre le plus rapidement à sa requête.

La beauté du routage Anycast est qu'il est complètement transparent pour l'utilisateur final. Peu importe où se trouve l'utilisateur ou quel serveur répond à sa requête : l'adresse IP est toujours la même. Cela rend le système extrêmement flexible et résistant. Si un serveur se déconnecte ou devient surchargé, le trafic peut facilement être redirigé vers un autre serveur sans perturber l'utilisateur.

Cependant, il est important de souligner que « CDN » est un terme générique qui peut désigner une grande variété de services, chacun avec ses propres particularités. Tous les CDN ne sont pas créés égaux, et pour tirer le maximum d'avantages d'un CDN, il est essentiel de comprendre ses spécificités et de le configurer correctement.

Dans de nombreux cas, l'utilisation de CDN commerciaux courants peut ne pas apporter les avantages escomptés. Par exemple, alors qu'un CDN peut avoir des POP près de Mountain View, une mauvaise configuration ou une conception sous-optimale du CDN peut empêcher ces POP d'avoir une copie en cache du contenu du site. Dans ce cas, les requêtes des robots d'exploration Google sont redirigées vers l'origine, ce qui peut dégrader la vitesse de réponse.

Ce problème peut être particulièrement grave si l'origine ne dispose pas d'un système de mise en cache local capable de fournir du contenu aux robots en quelques millisecondes. Dans ce cas, l'utilisation d'un CDN peut finir par ralentir les requêtes au lieu de les accélérer, ce qui a un impact négatif sur le temps de crawl et, par conséquent, sur la visibilité du site dans les résultats de recherche Google..

Le problème peut être encore exacerbé si le CDN n'est pas correctement configuré pour la mise en cache. Certains CDN offrent un grand nombre d'options de configuration, chacune pouvant avoir un impact significatif sur les performances. Si ces options ne sont pas configurées correctement, le CDN peut ne pas être en mesure de diffuser efficacement le contenu mis en cache, ce qui peut entraîner des temps de réponse plus longs.

La meilleure façon de surveiller les statistiques de Google Crawl.

Indépendamment des technologies utilisées et des fournisseurs impliqués, le moyen le plus efficace de surveiller les statistiques d'exploration de Google et le temps de réponse moyen consiste à utiliser Google Search Console. Le panneau Crawl Stats fournit des informations détaillées et à jour sur l'activité d'exploration de votre site Web par Google. Nous vous recommandons d'accéder à cette section une fois par semaine pour suivre de près les performances de votre site.

Pour un fonctionnement optimal, le temps de réponse moyen doit toujours être inférieur à 200 millisecondes. Cette valeur représente le temps théorique maximum nécessaire à Googlebot pour obtenir une réponse de votre serveur, et une valeur inférieure signifie que Googlebot peut explorer vos pages plus efficacement, améliorant ainsi votre budget d'exploration et votre considération par Google. Vous pouvez suivre votre temps de réponse moyen via le lien à Statistiques d'analyse de Google Search Console.

La valeur de 200 ms n'est pas une valeur aléatoire, mais plutôt la valeur maximale explicitement indiquée par Google https://developers.google.com/speed/docs/insights/Server?hl=it, et devrait être une bonne pratique à suivre, comme indiqué dans les suggestions pour améliorer la réponse du serveur.

Améliorer le temps de réponse du serveur --- Google-PSI

Si vous remarquez que votre temps de réponse moyen est supérieur à 200 millisecondes, ou si vous rencontrez des problèmes avec vos statistiques d'analyse, n'hésitez pas à nous contacter. Nos experts sont disponibles pour vous aider à trouver une solution rapide et à améliorer les performances de votre site web. N'oubliez pas qu'un site Web rapide et réactif n'est pas seulement bénéfique pour vos utilisateurs, c'est également un facteur clé d'un bon référencement.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Facebook, Inc. détient les droits sur Facebook® ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systèmes sans avoir à migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
Retour en haut de page