Google utilise les données de Chrome pour mesurer la vitesse du site - Arobasenet.com
Rechercher :


Google utilise les données de Chrome pour mesurer la vitesse du site

John Mueller de chez Google a évoqué, en aparté du SMX Munich de Mars dernier, la manière dont Google utilise les données pour évaluer la vitesse du site de nos jours.

Google utilise les données de Chrome pour mesurer la vitesse du site

Cette confidence a été recueillie par Tom Anthony, auteur invité chez Moz et VP d’une agence Web.

La version courte de son échange avec John Mueller, c’est que Google utilise maintenant des données de performance agrégées à partir des utilisateurs de Chrome qui ont opté en tant que DataPoint pour l'évaluation de la vitesse de chargement du site Web.

Et aussi comme un signal en ce qui concerne les classements.

Il s'agit d'un mouvement positif, car cela signifie que nous n'avons pas besoin de traiter l'optimisation de la vitesse de chargement du site pour Google comme une tâche distincte de l'optimisation pour les utilisateurs (UX).

Auparavant, John Mueller n'avait pas été clair sur comment Google évalue la vitesse du site, et elle a été généralement considérée comme mesurée par Googlebot lors de ses visites. Une croyance renforcée par la présence de graphiques de vitesse dans la Search Console.



Cependant, Googlebot n'est pas construit pour reproduire la façon dont les visiteurs réels se comportent sur un site, et si la tâche de l'exploration est devenue plus complexe, il est logique que Googlebot peut ne pas être le meilleur mécanisme pour cela.

Google Search Console


Tout d'abord, Tom Anthony tente de clarifier sa compréhension de ce que la métrique "temps de chargement d’une page” dans la Search Console de Google nous dit.

John Mueller, via un post sur un forum de Google, apporte un éclaircissement sur le processus :

Ce n’est pas techniquement le “téléchargement de la page” mais plutôt la “réception de données en réponse à la demande d'une URL”.

Ce n'est pas basé sur le rendu de la page, il comprend toutes les demandes faites. Si vous avez des fichiers vraiment gros qui sont fréquemment demandés (par exemple, de gros fichiers PDF), ce nombre pourrait remonter avec la même “vitesse” (Speed) par rapport à d'autres sites. Ce n'est pas si commun.

Le mélange le plus commun est une variété de pages HTML + des ressources intégrées comme les CSS, js, images, etc.

Certains d'entre elles seront servies comme contenu statique et être très rapides, d'autres pourraient avoir besoin d'être compilées au moment d’être servies (pages html). Sans regarder les fichiers logs pour voir le mix réel, il est impossible de savoir avec certitude.

Habituellement, j'utilise ce graphique (Statistiques sur l’exploration de la Search Console, ndlr) quand je vois un site qui se fait explorer beaucoup plus lentement que je m'attends à ce qu'il soit analysé.

Par exemple, si un site en évolution rapide se plaint de nouveaux contenus qui ne sont pas indexés, regarder cela peut vous donner une vue qui permet de savoir si c'est en raison de la vitesse du serveur ou pas.

Si je vois des choses dans la tranche 50-200Mo téléchargés par jour, ce qui semble bien, et si je vois des choses à 2000ms (millisecondes), c’est qu’il y a quelque chose qui cloche (c'est la moyenne sur toutes les demandes pour ce jour-là, de sorte que certains des téléchargements seront probablement beaucoup plus lents).

Puisque c'est juste le temps de demande d’une URL, pas le temps de la rendre ou l’afficher, les chiffres qui sont élevés auront presque certainement un effet sur la visibilité de l’utilisateur aussi.

Se concentrer aveuglément sur ce chiffre n'a pas de sens. Si un site est la plupart du temps statique, et qu’il est lent à répondre, alors nous ne manquons pas de contenu en explorant plus lentement. Nous l'avons déjà indexé de toute façon.

Le graphique est également utile si vous effectuez des modifications de serveur/backend et que vous souhaitez double-vérifier la réponse agrégée.

Si elle a un gros pic vers le haut ou vers le bas à ce moment-là, vous pouvez supposer que quelque chose a bien ou mal fonctionné.

Le rapport de l'expérience utilisateur Chrome


Introduit en Octobre de l'année dernière, le rapport de l’expérience utilisateur Chrome “est un ensemble de données publiques des métriques clés de l'expérience utilisateur pour les premières origines sur le Web”, selon laquelle  :

Les données de performance incluses dans le rapport proviennent des conditions réelles, agrégées par les utilisateurs de Chrome qui ont opté pour synchroniser leur historique de navigation et avoir l'utilisation des rapports statistiques activés.

Essentiellement, certains utilisateurs de Chrome permettent à leur navigateur de rapporter des métriques de temps de chargement à Google. Le rapport a actuellement un ensemble de données publiques concernant le premier million d’origines.

Rappelons à toute fin utile que le rapport de PageSpeed Insights, qui utilise désormais les données réelles de Chrome, a maintenant plusieurs éléments différents que vous pouvez consulter ici.

Faites attention aux utilisateurs


D’une manière importante, et d’après Tom Anthony, cela signifie qu'il y a des changements que vous pouvez faire à votre site que Googlebot n'est pas capable de détecter, mais qui sont encore détectés par Google et utilisés comme un signal de classement.

Par exemple, l’on sait désormais que Googlebot ne prend pas en charge le crawling HTTP/2, mais, cependant, nous savons que Google sera en mesure de détecter les améliorations de vitesse que vous obtiendrez en déployant HTTP/2 pour vos utilisateurs.

Essentiellement, cela signifie qu'il n'y a plus de raison de s'inquiéter de la vitesse de chargement pour Googlebot, et vous devriez plutôt vous concentrer simplement sur l'amélioration des choses pour vos utilisateurs.

Vous avez encore besoin de prêter attention à Googlebot à des fins d'exploration, ce qui est une tâche différente.