Google Crawl Stats & TTFB : une relation critique sous-estim√©e - ūüŹÜ Serveur g√©r√©
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

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modèle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

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.
Remonter en haut