Nous ajoutons aujourd’hui un nouveau facteur dans nos algorithmes de classements : la vitesse du site. Cette dernière reflète la rapidité avec laquelle un site répond aux requêtes.
Améliorer le temps de réponse d’un site est important — non seulement pour les propriétaires des sites, mais aussi pour les internautes[...], c’est pourquoi nous avons décidé de la prendre en compte lorsque nous établissons nos classements des résultats de recherche. Nous utilisons une variété de sources pour déterminer la vitesse d’un site par rapport aux autres sites.

Pour l'instant ça ne concerne que google.com (et pas .fr) mais cela sera surement étendu au moteur de recherche français dans quelques semaines...

+ d'infos ici :
http://www.goopilation.com/2010/04/goog ... erche.html

Yes ! Et bien tant mieux, ça m'arrange. Merci pour le lien

moi, ça m'arrange pas ... j'ai (durant une période) pour sécuriser et facilité la maintenance de réseaux de site externalisé les serveurs par des requetes cUrl avec des pseudo façades sur les domaines publiés ... et donc, il semblerait que je risque de devoir tout refondre et inverser totalement le processus pour pouvoir palier à cette lenteur abominable :@ pas cool

mais c'est vrai que c'est un paramètre important !...

mais comment est-ce géré ? est-ce juste la réponse html brut du serveur (status:200) ou est-ce le temps de chargement de l'ensemble des éléments du site ? (images en BG de 2000*3000) ?

et c'est dommage que ça ne prenne pas en compte le travail de développeurs qui font une couche supplémentaire de full Ajax (non intrusif) dans le but d'alléger les transfert et ainsi dynamiser les chargement de page !...

* autres : :: y a t il une incidence sur le fait que certains site génèrent leurs rendu dans des buffer (la plupart des MVC et CMS) alors que d'autres distillent au fur et à mesure des infos au navigateur !... le temps de réponse du premier sur le second est pénalisé, alors que le contenu et/ou le contenant est "souvent" plus propre ...

allons nous voir des sites au designs élaborés à la Face2Book émerger de partout !?

à voir à l'usage :s mais merci

A mon avis ce n'est pas le temps de réponse de la page HTML seule mais bien le chargement de l'ensemble des éléments des pages qui est prise en compte.
D'ailleurs c'est ce que les outils indiqué par Google prennent en compte

A mon avis ce n'est pas le temps de réponse de la page HTML seule mais bien le chargement de l'ensemble des éléments des pages qui est prise en compte.
D'ailleurs c'est ce que les outils indiqué par Google prennent en compte

dans ce cas, on perd vite tous les avantage plébiscités avec l'arrivé des grosses connexions adsl pour tous !... de bon Gros designs et des Flash qui claquent de partout (sauf chez moi) et ça au bénéfice des sites pour wap et autres iMode (ho les vielles ref ^^) ...

est-ce une avancée technologique !?

je comprend bien que ce soit un point important dans un critère pondérateur du site : "la navigation" ... mais elle doit etre en adéquation avec le fonctionnement du site !

j'ai des sites avec de gros design qui fonctionnement en 3G parce que tous les éléments lourd ne sont chargés qu'une seule fois (navigation en ajax) !... maintenant, quand google viens l'indexer à 2h du mat (heures des backup serveur) ben ... il lui faut 3 minute pour charger la page ! ...

Lol toi aussi ton site est super lent pendant les backups. Moi il l'est vers 4h du matin.

Quand je vois pour certains mots clés que les premiers articles datent de 2003 par exemple, je me dis presque que cette question de lenteur est une blague ...

Nours c'est vrai que ton site à 1h50 est vraiment ... très lent. plus de trente secondes pour avoir l'image de fond ..

Oui enfin comme ils disent c'est un nouveau signal mais cela ne compte pas autant que la pertinence d'une page.

Sinon leurs arguments en faveur d'un site rapide tiennent la route : confort pour le visiteur, réduction des coûts opérationnels.

Pour les coûts opérationnels on pourra toujours objecter que cela peut se reporter sur une maintenance plus coûteuse. Mais bon finalement c'est tant mieux pour nous, ça fait plus de taff en continu et le bilan financier peut être neutre.

D'un autre côté se servir d'une usine à gaz pour pondre simplement quelques lignes de code, il serait temps de limiter un peu la tendance. D'une part ça dévalorise notre travail et d'autre part le bilan énergétique est mauvais. Et puis quand on les utilise, cela poussera à ne charger que les modules nécessaires ce qui est le minimum pour un travail optimisé que tout le monde ne prend pas la peine de faire.

On peut trouver aussi que c'est un peu plus de travail humain pour compenser ou maitriser des automatismes lourds et gros consommateurs d'énergie. De ce point de vue, même si ce n'est pas le but initial, cela va un peu contre la tendance actuelle qui est de minimiser aux maximum les emplois au profit des machines.

Oui enfin je rêve un peu. Mais pourquoi les programmes informatiques serait-ils exonérés de faire des économies d'énergie quand c'est possible ? Après tout il n'est pas si loin le temps où l'optimisation consistait à avoir un programme le plus rapide pour un minimum de ressources.

Bon après je ne dit pas pour autant de faire machines arrières toute vapeur, c'est histoire de juste équilibre, mais je trouve que la tendance actuelle, avec l'accroissement des performances serveurs, ne s'en préoccupait plus du tout. D'ailleurs si je parlais "empreinte écologique" d'un programme ça ferait complètement décalé, non ? Hou là oui, faut que j'aille me coucher

Un exemple tout simple, en tapant http://www.google.fr/search?hl=fr&q=app ... qli+&meta=

Le premier résultat est un article de 2004. Comment pourrait-il m'apprendre ce que je cherche correctement ? C'est comme en tapant Php Orienté objet, vous allez tomber sur beaucoup de vieux articles sur la POO de php4. Autant dire avec les méthodes de construction qui porte le même nom que la classe, et j'en passe, sans encapsulage ni choix de visibilité, et j'en passe ...