Google Rank prend en compte la vitesse de chargement

[TrocWeb]

Google a annoncé sur son blog officiel que les algorithmes de classement des sites Internet indexés incluent maintenant un critère sur la rapidité de chargement des pages d’un site.

Cela signifie que les pages se chargeant rapidement apparaîtront plus haut dans les résultats de recherche sur Google. Auparavant, les critères principaux utilisés par le moteur de recherche étaient destinés à maximiser la pertinence des résultats et à lutter contre les abus. Cette fois le nouveau critère n’a rien à voir avec ces objectifs.

Il s’agit ici pour Google d’obliger les sites internet à améliorer leur temps de réponse. Cela peut être fait par exemple en nettoyant le code d’un site, mieux compresser les images, améliorer le matériel, passer à un meilleur hébergeur… Donc la plupart du temps, des investissements matériels et humains sont nécessaires.

Pour contrer les arguments des webmasters réticents, Google souligne que ces investissements sont rentables en citant une étude publiée lors de la conférence Velocity 2009 : augmenter la rapidité de chargement d’un site augmente à la fois les revenus, et fait baisser les coûts de hardware.

Améliorer Internet : la fin justifie-t-elle les moyens ?

Cette annonce va à n’en pas douter provoquer une forte activité chez les professionnels de l’Internet : perdre des places dans Google Rank peut provoquer la mort d’un site. En ce sens, cette mesure peut être comprise comme un chantage de Google qui dirait en substance « améliorez votre temps de réponse, ou vous mourrez ». C'est pour rassurer les inquiets que Matt Cutts, chef de l'équipe Webspam chez Google, précise sur son blog que « moins de 1 % des résultats de recherche vont changer suite à l'ajout du critère de vitesse dans le classement ».

Ce n’est pas la première fois que le géant met son poids dans la bataille pour améliorer le web. On se souvient que son support de l’HTML5 sur Youtube avait fait couler beaucoup d’encre sur la fin annoncée des lecteurs vidéo Flash, et que Google pousse, avec d'autres, pour la mort de IE6.

Pour vérifier les performances de votre site, Google vous propose des outils développés en interne et d’autres venants de tierces parties. En ce qui concerne PCI, l'équipe n'a pas attendu Google pour travailler à améliorer le code. Une version entièrement nouvelle de votre site d'information préféré est prévue dans les mois qui viennent...

Source Pc Impact

[Nullette]

Bonjour,

c'est passionnant.

Et que fait une Nulle comme moi ?

J'ai testé le "page speed" :

The following resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers. Specify an expiration at least one month in the future for resources that should be cached, and an expiration in the past for resources that should not be cached:

On spécifie comment l'expiration ? Il s'agit des images de mon logo.

Favicons should have an expiration at least one month in the future:

et pour le favicon ? Comment on indique l'"expiration" ???!!!

[Kent]

Salut salut,

Sympa l'article, juste pour vous signaler qu'il existe aussi YSlow un addon par yahoo qui permet d'évaluer les performances d'un site web, les suggestions d'améliorations sont pas mal. (ceci dit certaines suggestions d'améliorations peuvent paraître fantaisistes pour un site à petit budget tel que l'utilisation d'un Content delivery Network ou autre).

Nulette ,

Tu peux spécifier dans un .htaccess certaines choses qui permettent d'améliorer le temps de chargement des pages web.

Tu peux compresser ce qui est CSS et JS avant l'envoi au navigateur via le mode deflate d'apache par exemple.

Active le module puis dans un .htaccess tu peux utiliser ce genre d'instruction

AddOutputFilter DEFLATE css js

Ou encore, avec le module expires (toujours chez apache) tu peux définir un délais d'expiration pour ton contenu par défaut.

ExpiresDefault "access plus 10 years"

Ou encore par type ( via le site officiel ):

 ExpiresActive On                  # enable expirations
   ExpiresByType image/gif A2592000  # expire GIF images after a month
                                     #  in the client's cache
   ExpiresByType text/html M604800   # HTML documents are good for a
                                     #  week from the time they were
                                     #  changed, period

Voilà voilà, tout ça pour dire que les améilorations se font aussi coté client, on y pense pas souvent.

Vous pouvez aussi compresser hors transfert (minifier) vos fichier JS ou CSS

++ Kent

[Remi]

Les meilleures optimisations restent tout de même au niveau de la programmation elle-même : multiples accès à la base de données, construction poussive de la page par petits modules empilés, multiples JS qui bloquent l'affichage chez le client, accès à 45000 modules JS externes, etc...

Bon, mais je ne crois pas trop à cette annonce mais si cela peut sensibiliser les webmasters au problème de la vitesse, cela ne sera pas inutile... En tout cas, c'est une pierre lancée dans le jardin de Macromedia car ceux qui vont avoir le plus peur, ce sont les concepteurs de sites full flash.

[Nullette]

Merci Kent,

mais tu me parles de modules sur Apache... c'est du charabia pour moi

J'ai un petit site en xhtml, je suis sur un serveur mutualisé qui est, je crois, sur Debian.

[Kent]

, tu peux dans ce cas suivre aussi les conseils de Rémi.

Pour ceux qui ont la main sur leur serveur, vous pouvez tenter les optimisations coté HTTP.

Mais avant cela et comme dit Rémi, il est évident que ça doit être performant coté serveur aussi .

[adn]

Facebook a de quoi améliorer la perfo pour leur référençement car çà rame souvent, surtout avec leur couche ajax. Ceci dit je ne m'inquiète pas pour eux, ils en ont pas besoin

[Leonick]

En tout cas, c'est une pierre lancée dans le jardin de Macromedia car ceux qui vont avoir le plus peur, ce sont les concepteurs de sites full flash.

je ne sais même pas, car ce qui semble être pris en compte c'est uniquement le temps d'upload et pas d'exécution.

Ce qui fait qu'une page web qui charge une coque vide flash ne va peser quasiment rien. Après, au niveau du navigateur, quand le flash va commencer à charger la vidéo de 15 Mo pour le splash screen, ça va faire mal.

[mx-quou]

c'est bien mieux pour un surf plus fluide

[Leonick]

qu'est ce qui est mieux pour un surf rapide ? d'avoir une vitesse d'upload plus rapide ?

si c'est pour ensuite se taper 15 secondes d'initialisation des différents javascript dans le navigateur, tout ça pour donner un effet web 2.0

étant donné que gg ne calcule que la vitesse d'upload et pas celle d'exécution de la page, comme peut-on quantifier la vitesse d'affichage ?

[ams51]

étant donné que gg ne calcule que la vitesse d'upload et pas celle d'exécution de la page

D'où vient cette affirmation? j'ai cherché et je n'ai pas trouvé de référence là dessus...

Personnellement je pense que c'est le contraire

[captain_torche]

Il est difficile de déterminer le temps d'exécution d'une page, notamment à cause des javascripts qui pourraient ralentir cette exécution.

En ce qui concerne le classement, et ce que je comprends de l'article de Google, seuls les sites très lents pourraient être pénalisés : à mon avis, ils activeront un flag "site très lent" à ces sites, qui les déclasseraient au profit de sites presque aussi pertinents et plus rapides.

[Leonick]

D'où vient cette affirmation? j'ai cherché et je n'ai pas trouvé de référence là dessus...

Personnellement je pense que c'est le contraire

si on ne trouve rien qui dit le contraire c'est que c'est ça

Sinon, ils seraient obligés de vérifier tes scripts js pour voir si rien ne fait planter, si le js est bien compatible avec tous les navigateurs, etc...

Là on ne voit qu'une durée d'upload et de taille (éventuellement à compresser), or, ce qui prend du temps c'est la création de la page, pas le transfert via le réseau (en dehors des mp3 et vidéo démarrés lors du chargement de la page)

Franchement, combien gagne-t-on comme temps à envoyer un js de 12 Ko sous forme compressée au lieu de 30 Ko non compressé ? Combien gagnerait-on comme temps à envoyer un js non compressé de 15 ko qui ne contiendrait que les fonctions dont on a réellement besoin au lieu d'utiliser les frameworks les plus courants (genre script.aculo.us et autres) ?

[Kioob]

Dans les outils Webmaster de Google on voit clairement que Google mesure le temps de réponse et le temps d'affichage de manière très distinctes. En effet j'ai un site avec des graphiques "temps de réponse" ayant une moyenne de 300ms et des graphiques "temps d'affichage" de l'ordre de 4 secondes.

Et à mon avis, ils vont opter pour ce deuxième critère, bien plus exhaustif.

Ca fait déjà un moment que des rumeurs de ce genre circulent, et chez nous des décisions ont déjà été prises en ce sens (comme virer certaines intégrations publicitaires trop lourdingues).

La bonne nouvelle pour moi c'est que ça va peut-être forcer les développeurs à prêter attention à ce genre de choses.

Edit : dans les "Outils pour les webmasters", dans "Diagnostic => Statistiques sur l'exploration", on a le temps de téléchargement des pages. Tandis que dans "Labos => Performances du site" on a le temps d'affichage réel.

[Remi]

Il est difficile de déterminer le temps d'exécution d'une page, notamment à cause des javascripts qui pourraient ralentir cette exécution.

Oui, c'est très difficile : à quel moment considère t-on que la page est chargée ?

Pas facile, car le site peut redonner la main et continuer à exécuter/charger en arrière-plan : sur une machine lente, on a la main mais le curseur ne répond pas (ou il faut cliquer 15 fois pour que le clic soit pris en compte) car les scripts occupent parfois 100% du temps machine...

C'est un peu comme au démarrage de Windows : il nous donne la main très rapidement, mais en pratique il faut mieux attendre 1 ou 2 minutes qu'il ait fini toutes ses salades. Cela évite de commencer la journée en pestant contre son ordinateur...

[captain_torche]

Exactement !

Sur mon site, par exemple, certains javascripts (notamment les lightbox) s'activent en arrière-plan alors que la page est déjà entièrement fonctionnelle. Faut-il considérer que la page n'est pas disponible tant que ces scripts n'ont pas fini de tourner ?

[paolodelmare]

Faut-il considérer que la page n'est pas disponible tant que ces scripts n'ont pas fini de tourner ?

Au hasard GA ? Ça serait le comble.

[Leonick]

effet j'ai un site avec des graphiques "temps de réponse" ayant une moyenne de 300ms et des graphiques "temps d'affichage" de l'ordre de 4 secondes.

tu le vois où le temps d'affichage ? moi je n'ai que temps de chargement

comment peut-on calculer un temps d'affichage sachant que chaque navigateur va réagir différemment. En plus, comme dit au dessus, moi ce qui m'intéresse ce n'est pas le temps d'affichage mais le temps à partir duquel le navigateur redeviendra opérationnel, c'est à dire que je pourrais interagir avec lui, scroller, ...

[Kioob]

ici :

dans les "Outils pour les webmasters", dans "Diagnostic => Statistiques sur l'exploration", on a le temps de téléchargement des pages. Tandis que dans "Labos => Performances du site" on a le temps d'affichage réel.

Pour ce qui est du "choix" du navigateur, pourquoi n'auraient-il pas le droit d'utiliser leur navigateur maison ?

Pour ce qui est des détails techniques, as-tu au moins essayé PageSpeed dans Firefox ou l'équivalent intégré à Chrome ? C'est plutôt bien foutu, bien que pas parfait.

Par exemple, le "domready" et la fin de chargement "complète" sont clairement identifiés, comme dans la plupart des outils du genre.

[Leonick]

ici :

dans "Statistiques sur l'exploration" j'ai "Temps de téléchargement d'une page (en millisecondes)" et dans "Performances du site" j'ai "temps de chargement requis dans un navigateur (en secondes)."

pour moi c'est juste une question de sémantique, mais ça représente la même chose. Une fois que la page est chargée, il faut qu'elle s'exécute (javascripts, vidéo, audio, ... appelés par flash) et nulle part il n'en est question

Pour ce qui est du "choix" du navigateur, pourquoi n'auraient-il pas le droit d'utiliser leur navigateur maison ?

peut-être parce que ça n'est pas représentation des navigateurs généralement utilisés sur le web

Pour ce qui est des détails techniques, as-tu au moins essayé PageSpeed dans Firefox ou l'équivalent intégré à Chrome ? C'est plutôt bien foutu, bien que pas parfait.

Par exemple, le "domready" et la fin de chargement "complète" sont clairement identifiés, comme dans la plupart des outils du genre.

sauf que cela dépendra de ta configuration, nombre de plugins installés dans FF, y compris ceux d'abode et autres, gestion de la mémoire cache du navigateur,... Donc ingérable pour faire un quelconque pronostic de délais de chargement

[Kioob]

dans "Statistiques sur l'exploration" j'ai "Temps de téléchargement d'une page (en millisecondes)" et dans "Performances du site" j'ai "temps de chargement requis dans un navigateur (en secondes)."

pour moi c'est juste une question de sémantique, mais ça représente la même chose. Une fois que la page est chargée, il faut qu'elle s'exécute (javascripts, vidéo, audio, ... appelés par flash) et nulle part il n'en est question

Tu y mets beaucoup de mauvaise foi là : j'ai personnellement un facteur de 10 entre les deux mesures, et sur la deuxième page il y a une partie des conseils fournis par PageSpeed concernant le temps d'affichage. Que te faut-il d'autre comme preuve ? Qu'ils remplacent "chargement" par "affichage" ? C'est juste la traduction qui te chagrine ?

peut-être parce que ça n'est pas représentation des navigateurs généralement utilisés sur le web

Et en quoi la société Google se doit elle d'être neutre à ce sujet ? Cela te choque vraiment qu'elle mette en avant les sites les plus efficaces avec ses propres produits ? C'est comme s'il était prouvé qu'ils mettaient en avant les sites utilisant adsense/adwords, on peut le regretter, mais après tout Google reste une société non ?

sauf que cela dépendra de ta configuration, nombre de plugins installés dans FF, y compris ceux d'abode et autres, gestion de la mémoire cache du navigateur,... Donc ingérable pour faire un quelconque pronostic de délais de chargement

Et pourtant certains en font leur métier et font de l'audit en ce sens avec de très bons résultats à la clé. La "performance web", ça n'est pas nouveau, ça arrive juste un peu tard en France. Il y a pas mal de bouquins, blogs et autres medias qui y sont consacrés ; donc ça doit pas être si ingérable que ça non ?

[ams51]

si on ne trouve rien qui dit le contraire c'est que c'est ça

Je n'ai rien trouvé qui dit quoi que ce soit. Donc les deux hypothèses sont à envisager.

Mais Google communique beaucoup plus sur le temps de chargement "vue de l'internaute"... En tout cas c'est ce qu'il me semble.

Sinon, ils seraient obligés de vérifier tes scripts js pour voir si rien ne fait planter, si le js est bien compatible avec tous les navigateurs, etc...

Ils n'ont pas à vérifier les scripts ils ont une toolbar pour ça. Elle renvoie assez de données pour estimer la rapidité d'exécution des scripts.

It shows you the average page load time for pages in your site, the trend over the last few months, and some suggestions on how to make the pages load faster. Page load time is the total time from the moment the user clicks on a link to your page until the time the entire page is loaded and displayed in a browser. It is collected directly from users who have installed the Google Toolbar and have enabled the optional PageRank feature.
/>http://www.google.com/support/webmasters/bin/answer.py?answer=158541&hl=en

Dans les outils Webmaster de Google on voit clairement que Google mesure le temps de réponse et le temps d'affichage de manière très distinctes. En effet j'ai un site avec des graphiques "temps de réponse" ayant une moyenne de 300ms et des graphiques "temps d'affichage" de l'ordre de 4 secondes.

Je serais eux je prendrais la seconde donnée. L'objectif est d'améliorer l'expérience utilisateur et non la performance des crawlers.

On peut dire ce qu'on veut sur Google mais ils ont du bon sens et sont constant dans leur choix.

Oui, c'est très difficile : à quel moment considère t-on que la page est chargée ?

Quand le page rank de la GG toolbar d'affiche... En gros quand le navigateur affiche le favicon dans l'onglet.

Exactement !

Sur mon site, par exemple, certains javascripts (notamment les lightbox) s'activent en arrière-plan alors que la page est déjà entièrement fonctionnelle. Faut-il considérer que la page n'est pas disponible tant que ces scripts n'ont pas fini de tourner ?

Je le pense

[Remi]

Je le pense

D'accord, mais c'est là que les soucis commencent :

il y a une différence énorme entre le petit diaporama Flash qui continuent de charger des images en arrière plan pendant 30 secondes et les scripts qui moulinent plein de trucs et qui bloquent la machine.

Sur un PC peu puissant, la différence est énorme...

Ce qu'il faudrait, c'est mesure l'occupation processeur des scripts...

[ams51]

Peu importe la machine GG fait des stats sur beaucoup de points. Il indique d'ailleurs la validité du chiffre donné. J'ai "These estimates are of low accuracy (fewer than 100 data points)" sur un site et "These estimates are of high accuracy (more than 1000 data points)" sur un autre.

[Dudu]

Salut

peut-être parce que ça n'est pas représentation des navigateurs généralement utilisés sur le web

Pareil que Kioob: qu'est-ce qu'ils en ont à f**tre ? Google est une société avec une force de frappe immense, et ils peuvent largement se permettre d'imposer leur vision du web, en conformité bien sûr avec leurs attentes commerciales. Ils ne s'en sont jamais privés jusque là.

Preuve ? Personne n'a que faire de mettre les bonnes balises au bon endroit comme préconisé par le w3c. En revanche, tout le monde va bien sagement mettre sa petite meta pour les urls canoniques, sa petite meta verify pour Analytics, ne pas mettre tous les liens dans le pied-de-page, changer régulièrement d'ancre de texte pour ne pas être classé spammy, etc. Pourquoi ? Parce que c'est Monsieur Google qui te le demande et que si tu ne fais comme Monsieur Google te le demande, alors tu perds une part non négligeable de ton trafic.

Pour la vitesse de chargement, il y a fort à parier que ce sera la même chose: ils diront "nous on a décidé d'utiliser nos outils maison. Vous calculez différement de nous ? Fort bien, mais nous avons raison, vous avez tort, et on vous pénalise".

Pourquoi feraient-ils différement alors que de toute façon tout le monde va s'aligner sur leurs désidératas ?