Comment les outils Google pour les webmasters mesurent-ils exactement les «performances du site»?


27

Je travaille depuis deux mois maintenant sur l'amélioration de notre temps de réponse (principalement côté serveur) sur un nouveau forum (un tout nouveau produit d'un point de vue technique) que nous avons lancé en Allemagne il y a quelques mois et je suis beaucoup surpris par les résultats que j'obtiens. Je surveille notre temps de réponse à l'aide des journaux Apache et de notre propre implémentation de la balise Boomerang .

En utilisant mes statistiques, je peux voir que notre nouveau produit répond dans environ 680 ms alors que notre ancien produit répondait dans environ 1050 ms. D'un autre côté, Google Webmaster Tool nous indique que nos pages ont un temps de réponse moyen d'environ 1500 ms aujourd'hui, alors qu'il était de 700 il y a trois mois avec notre ancien produit.

J'ai pensé que GWT tenait compte des mesures côté client, j'ai donc ajouté quelques mesures sur notre balise Boomerang et tout semble très bien. J'ai également exécuté des pages aléatoires sur ySlow et la vitesse de page de Google et tout semble mieux qu'auparavant. Nous avons 82% sur l'outil de vitesse de page de Google, ce qui est assez cool pour un site avec des publicités :)

Dernièrement, nous avons signé un accord avec Akamai pour utiliser deux de leurs produits: CDN pour nos fichiers statiques (nous utilisions un autre CDN auparavant mais ce n'était pas très efficace) et RMA pour améliorer les routes des réseaux. Nous avons également introduit un nouveau mécanisme de cache agressif pour garantir que la plupart des pages servies aux robots d'exploration sont mises en cache par notre grille memcache. Après avoir vérifié mes métriques, il semble que ces changements soient passés de 650 ms à environ 500 ms, ce qui est bien (toujours pas génial mais c'est définitivement une amélioration). Mais les outils pour les webmasters continuent de signaler un temps de réponse moyen croissant où nous le voyons diminuer dans le même temps.

Avez-vous déjà eu le même genre de comportement étrange sur vos sites tout en améliorant les performances? Avez-vous une idée de la façon de surveiller la même chose que Google avec les performances du site dans les outils pour les webmasters de Google afin que nous puissions améliorer notre site et vérifier en permanence si c'est ce que Google veut?

Edit 26/07/2011 : Merci pour vos réponses les gars! Néanmoins, je n'étais pas assez précis. Le problème principal que nous avons ne concerne pas la page des performances du site, mais celle des statistiques d'exploration pour l'instant. Nous avons probablement trouvé un problème de notre côté avec des pages très lentes (environ 3000 ms !!) et nous essayons de les corriger. Je vous tiendrai au courant dès que j'aurai quelques infos. Merci encore !

Réponses:


17

Selon les directives officielles

http://www.google.com/support/webmasters/bin/answer.py?answer=158541

Les performances du site sont une fonctionnalité expérimentale des laboratoires des outils pour les webmasters qui affiche des informations de latence sur votre site. (Pour voir les données de performances du site, vous devez ajouter et vérifier votre site dans les outils pour les webmasters.)

Le temps de chargement de la page est le temps total entre le moment où l'utilisateur clique sur un lien vers votre page et le moment où la page entière est chargée et affichée dans un navigateur. Il est collecté directement auprès des utilisateurs qui ont installé la barre d'outils Google et qui ont activé la fonctionnalité facultative de PageRank.

Étant donné que les utilisateurs peuvent souvent interagir avec les pages Web avant qu'elles ne soient entièrement téléchargées, il s'agit d'une interprétation très stricte de la vitesse du site Web . Mais il est raisonnable d'être très strict sur cette mesure, car si une page contient des tonnes de JavaScript dynamique et des annonces chargées dynamiquement, il est sans doute plus correct pour l'utilisateur de voir la page se charger lentement.

Par conséquent, la façon dont ils mesurent cela est en utilisant l'onglet Réseau dans les outils Google Chrome aka ctrl+ shift+ I.

onglet réseau dans les outils Google Chrome

Les deux événements pertinents sont DOMContent Event Fired(ligne bleue) et Load event fired(ligne rouge). Sur une page aléatoire ici sur ce site, cela signifie que les nombres sont d'environ 600 ms et 1,1 sec, respectivement. C'est beaucoup, beaucoup plus grand que le temps de téléchargement d'une page à partir de la ligne de commande wget- et reflète clairement le temps que le navigateur client passe pour rendre le contenu qu'il télécharge via HTTP.

(Cela me semble également un peu injuste, car un site Web avec toutes les pages statiques aura un énorme avantage sur celui qui personnalise dynamiquement chaque page pour l'utilisateur spécifique, mais je suppose que ce sont les pauses!)


2
Je conviens que cette mesure est injuste. Je suis vraiment contre le fait que Google me pénalise potentiellement pendant combien de temps mon dernier statut Twitter se charge de manière asynchrone et discrète, lorsque la viande de la page se charge presque instantanément. Pire, il semble qu'ils encouragent le format d'article de plusieurs pages que tout le monde déteste, car cela se chargera certainement plus rapidement.
Dave Ward

1
Si vous prenez en compte le fait que Google vend des annonces et que plus de demandes de pages équivalent souvent à plus d'annonces diffusées, il serait logique que G $ essaie d'encourager les sites à utiliser un format d'article de plusieurs pages.
runxc1 Bret Ferrier

@dave Google dit explicitement que les performances du site sont une fonctionnalité expérimentale de "laboratoires", pour être clair, il n'est donc pas certain que cela soit utilisé à des fins de classement.
Jeff Atwood

1
@Jeff, je pense que oui, à moins qu'ils n'aient changé d'avis depuis: googlewebmastercentral.blogspot.com/2010/04/…
Dave Ward

1
Cela signifie-t-il que tout ce qui s'exécute après window.onload n'est pas compté dans le temps de chargement de la page?
DisgruntledGoat
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.