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.

Informations sur l'auteur

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