Le dictat de Google a encore frappé et tout le monde est au garde-à-vous.
Google a annoncé vendredi qu’un signal lié à la vitesse d’affichage des pages est incorporé à l’algorithme.
Quelles sont les conséquences pour le référencement et comment faut-il appréhender ce nouveau paramètre ?
Plus grave encore, avons-nous vraiment des solutions ?
La récente mise à jour de l’infrastructure du moteur de recherche a fait couler beaucoup d’encre numérique au sein de la communauté du référencement et au-delà. Cette mise à jour surnommée Google Caféine a engendré son lot d’interprétations hasardeuses, mais la grande nouvelle concernait la prise en compte de la performance (vitesse d’affichage) des pages.
Non seulement un onglet intitulé Performance du site apparaît dans la console Google Webmaster Tools, mais Matt Cutts évoque la montée en puissance de ce paramètre et la récente annonce officielle donne quelques détails supplémentaires.
L’annonce officielle Google
Voici la traduction du billet posté vendredi sur le blog Google destiné à la communication avec les webmasters.
Utiliser la vitesse de site dans le classement des résultats de recherche
Vous avez entendu que nous (Google) sommes obsédés avec la vitesse dans nos produits et sur le Web. Dans cet effort, nous introduisons aujourd’hui un nouveau signal au sein de notre algorithme de classement des résultats de recherche : vitesse du site. La vitesse du site reflète la rapidité à laquelle il répond aux requêtes Web.
Accélérer les sites Web est important – pas seulement pour les responsables des sites, mais pour tous les utilisateurs d’Internet. Des sites plus rapides créés des utilisateurs contents et nous avons observé dans nos recherches internes que lorsqu’un site répond lentement, les visiteurs passent moins de temps dessus. Mais des sites plus rapides n’améliorent pas que l’expérience utilisateur ; des données récentes montrent qu’améliorer la vitesse du site réduit également les coûts d’opération. Comme nous, nos utilisateur portent un certain intérêt à la vitesse. C’est pour cela que nous avons décidé d’incorporer la vitesse du site dans les classements. Nous utilisons plusieurs sources pour déterminer la vitesse d’un site par rapport aux autres.
Si vous êtes un propriétaire de site Web, webmaster ou rédacteur, voici quelques outils gratuits que vous pouvez utiliser pour évaluer la rapidité de vos pages :
- Page Speed est un plugin Firefox open source qui évalue la performance des pages Web et donne des suggestions d’amélioration.
- YSlow est un outil gratuit de Yahoo! qui suggère des méthodes pour améliorer la vitesse du site.
- WebPagetest montre un déroulé des performances de chargement, ainsi qu’une liste d’optimisation.
- Webmaster Tools Labs > Performance Site montre la vitesse de votre site comme vont ressentir les utilisateurs autour du montre (exemple dans le graphe ci-dessous). Nous avons également blogue à propos de performance du site.
- D’autres outils sur code.google.com/speed
Alors que la vitesse du site est un signal nouveau, il ne porte pas autant de poids que la pertinence d’une page. Actuellement, moins de 1% des résultats de recherche sont affectés par le signal relatif à la vitesse du site dans notre implémentation et le signal s’applique seulement aux visiteurs recherchant en anglais sur Google.com. Nous avons lancé cette modification il y a quelques semaines après des tests rigoureux. Si vous n’avez pas observé beaucoup de changement concernant le positionnement de votre site, cela suggère que le paramètre vitesse du site n’a pas affecté votre site.
Nous encourageons à regarder de plus près la performance de votre site (les outils ci-dessus procurent un excellent point de départ) – non seulement pour améliorer votre positionnement, mais aussi afin d’améliorer l’expérience de tout le monde sur Internet.
Mon point de vue
Concernant l’annonce en elle-même, on sent bien que Google se positionne encore une fois comme grand ordonnateur d’Internet. Il dicte sa loi et nous devons subir. Sans revenir plus en détails sur la suprématie de Google, il est assez affligeant de se mettre au diapason d’un moteur de recherche, posant un grave souci déontologique par rapport à la liberté d’Internet. Une fois de plus, la loi de Google devient la loi d’Internet.
Par rapport à la performance du site, c’est un problème compliqué. J’ai intégré depuis le début d’année des analyses liée à ce paramètre au sein de mes audits. La totalité des sites que j’ai audité flanchent à ce niveau et mes sites ne sont pas mieux servis.
Ce qui me pose un sérieux problème concernant le jugement porté par Google sur la vitesse de nos site se rapporte à la présentation Performance du site dans la console Webmaster Tools. Voici un screenshot d’un site statique qui présente un code source le plus simple possible et les seuls éléments de scripts appartiennent à Google (Analytics et Adsense). Comme énoncé, les pages se chargent en moyenne à 1,9 secondes. D’après Google, ça serait dans une tranche plus rapide par rapport à 77% des sites Web.
Maintenant, le graphe pose clairement le site dans la zone « Lente » et la zone « Rapide » est délimitée à 1,5 secondes.
Franchement, il veut quoi de plus le Dieu Google ? Ce sont ces propres scripts qui sont les seuls éléments ralentissant ces pages et 1,9 secondes ne semble pas être un temps qui paraît outrageant.
Parmi mes audits, certains sites montrent des temps qui dépassent allégrement les 20 secondes. Quel danger se tient au-dessus de ces sites ? Si un site qui s’affiche en moins de 2 secondes est considéré comme lent, cela va gravement impacter la quasi totalité des sites dynamiques. Google veut-il que nous revenions à la fin des années 90 concernant la construction de sites Web ?
En plus, améliorer la vitesse d’un site pose des problématiques relativement complexes. Certes, un outil comme WebPagetest est très intéressant puisqu’il montre clairement les éléments ralentissant, mais certaines configurations plombent les résultats, alors qu’elles sont clairement conçues pour améliorer l’expérience utilisateur. En effet, j’ai des résultats mitigés qui remontent concernant les configurations sur la base de cache serveur. Par contre, les recommandations de la console Webmaster Tools met franchement l’accent sur la compression de données.
Puis modifier une grosse machine dynamique ne se fait pas en trois coups de cuillère à pot. Chaque cas est différent et cela implique parfois une refonte totale de l’architecture, ainsi qu’une complète révision du code. La multitude de scripts contenus sur une page entrave clairement la performance, mais c’est aussi censé améliorer l’expérience utilisateur. Certes, il y a de nombreux scripts qui s’apparentent plus à des gadgets qu’autre chose, mais il réside tout de même un grand nombre de scripts qui sont très intéressants pour l’utilisateur, tout en ne bénéficiant pas la performance.
Comment trouver le juste milieu ; surtout en se basant sur l’hallucinante limite érigée par Google ? Descendre en dessous de 1,5 secondes est tout simplement mission impossible pour la plupart des sites. Il faut aussi prendre en compte l’hébergement ; avec les serveurs mutualisés directement en ligne de mire. La solution du serveur est tout simplement surdimensionnée pour certains sites, mais seront ils pénalisés par défaut pour cause d’hébergement de qualité médiocre ?
Google est bien gentil avec son annonce qui pose son dictat, mais il ne donne pas assez de détails pour travailler sereinement. Les indications données dans Webmaster Tools sont intéressantes, mais je reste persuadé que la limite recommandé est trop basse.
Puis, ça serait tout de même le minimum syndical que les propres sites Google ne soient pas des paramètres qui ralentissent une page Web site.
Sachant que les connexions internet sont de plus en plus rapides, je trouve que Google tombe un peu comme un cheveu sur la soupe avec son signal vitesse du site. Vu les standards que le moteur de recherche veut ériger, nous effectuons un retour vers le début d’Internet en termes de construction de pages Web.
Je sens déjà que tout le monde se tracasse réellement à propos de ce paramètre. Les sites que j’ai audité sont déjà bien engagés dans une nette amélioration par rapport à la vitesse, mais dans les meilleurs des cas, il demeure impossible de cadrer avec la zone « Rapide » énoncée dans Webmater Tools.
Comme d’habitude, Google nous laisse en plan avec un impératif et très peu d’éléments qui permettent de travailler sereinement. Encore une fois, il va falloir se débrouiller entre nous avec une méthode empirique qui devient petit à petit un standard sans aide vraiment utile de la part du moteur de recherche.
Edit : la solution proposée par Thomas semble vraiment intéressante. A lire sur son blog à propos de HTMLminify.
Si le postulat de départ est qu’un site à l’affichage rapide est plus agréable pour l’internaute, je pense que nous sommes tous d’accord sur ce point.
Le deuxième argument de Google touche à notre sentiment écolo et notre bonne conscience :
» Faites des sites rapides, ils consommeront moins d’énergie pour tourner sur des serveurs gourmands en électricité »
Même si ce n’est pas totalement faux sur le fond, je trouve la ficelle un peu grosse, mais n’oublions pas que Google est installé en Californie, l’état américain qui se veut le plus « vert ». Ceci renforce aussi l’image de Google comme « chevalier blanc », qui résiste à la censure chinoise, qui produit de l’électricité propre, etc.
Pour ce qui est de la position de grand ordonateur du web, je crois que nous avons de toute façon à nous faire une raison, même si des gens comme toi ou moi balançons régulièrement ses 4 vérités à Google au travers de nos blogs, nous sommes bien obligés de courber l’échine car notre métier est de gagner des positions pour nos clients.
Ce qui me choque le plus dans cette annonce, c’est que l’introduction de ce paramètre remet en cause la notion de pertinence d’une page par rapport à la requête d’un internaute.
Une page rapide pourrait alors être mieux classée qu’une page plus pertinente ?
Bien sûr, le nombre de réponses pertinentes dans une SERP lisserait cet effet, mais tout de même, on assiste à une tendance allant plus à l’expérience utilisateur qu’à la pertinence d’une réponse.
Pour finir, je constate comme toi que ce qui ralentit majoritairement l’affichage de certaines pages, ce sont les services Google (analytics, traduction, etc.). C’est tout de même un comble.
Les futurs conseils en SEO seront peut-être un jour : « Si vous voulez améliorer votre classement, supprimez les services Google de votre site » ARF ! Je rigolerai bien ce jour là.
Paramètre ou pas dans l’algo, si la page ne se charge pas suffisamment vite, l’internaute repart d’où il vient et c’est pas top :
google > site A > google (même requête) > site B…
—-> pas bon pour site A
@AxeNet : il est absolument certain que la communication transversale au sein de Google est loin d’être efficace. C’est d’ailleurs symptomatique pour les entreprises de cette taille.
De ce fait, je ne pense pas qu’une amélioration soit pensable.
La recommandation d’éviter les services et outils Google sur les pages Web n’est pas une issue hypothétique.
@qqoqccp : je ne dis pas qu’il faut construire des sites lents, mais le standard de Google est impossible à atteindre.
De plus, un site peut paraître lent aux robots et rapide pour les visiteurs.
C’est bien plus compliqué que A=>B car il faut intégrer quelle est la véritable limite souhaitable; tout en impliquant plusieurs paramètres fluctuant.
C’est d’une stupidité sans nom. Tout d’abord, en tant qu’internaute, je préfère attendre 2 secondes de plus et avoir une information plus pertinente. Soyons d’accord, la critère de vitesse n’a rien à voir avec la pertinence d’une page web.
Ensuite, seul les « référenceurs » vont être au courant de ce paramètre. J’ai envie de dire tant mieux, mais cela va pénaliser les webmasters sans réelles compétences et suivi de l’actu réf. Il me semble que c’est l’inverse de ce que Google souhaite mettre en place, dans la logique.
j’en ferai peut-être un article au passage.
@AxeNet : j’ai oublié de préciser que l’annonce de Google suggère que la vitesse n’est pas un signal plus important que la pertinence. C’est un peu léger comme explication car il manque toujours l’essentiel qui est le degré de latitude.
@Keeg : c’est clair que ça va encore être un élément qui ne risque pas de révolutionner la création de sites Web. Quand j’observe la réaction pour s’accorder au bon sens d’une utilisation décente de H1, je n’ose même pas imaginer s’il faut se passer des scripts ou même remettre en cause la création en dynamique. De plus, les solutions dynamiques qui rapprochent un site de l’état statique font planter les outils d’évaluation de la performance. Y a comme un souci…
Salut !
Pour moi le problème est simple, Google sort un nouvel outil (page speed), et souhaiterait qu’un maximum de personnes l’integrent, histoire de plomber les bons scores de download de Yslow (l’outil équivalent de Yahoo).
Bon, il ne sort pas vraiment l’outil maintenant, mais il s’est décidé à en faire bonne presse 🙂
D’ailleurs, ne sort il pas le prétexte ‘téléchargez page speed pour mesurer la vitesse’ dans les préconisations ‘webmastertools’ ?
La vitesse s’améliore, c’est clair. Mais sur un site tel que celui sur lequel je travaille, le plus simple pour améliorer la rapidité de chargement de page, c’est de supprimer tous les tags ‘analytics’, ‘régies pubs’, etc..
Il n’y en a pas un mieux que l’autre !
Nico.
Il me semble que la plupart des annonces que fait Google sont souvent destinées à palier à leurs lacunes, comme l’ont été les sitemaps, les webmaster tools, etc : ils demandent aux éditeurs/webmasters de les aider à contourner les manques de leurs robots. Par exemple la réécriture d’url semble poser problème puisqu’un bot a du mal à saisir si il est dans un répertoire ou sur un rewrite. Et là, on constate encore la même chose. Un site lent, la plupart du temps parmi ceux que je vois, c’est le modèle « blog sapin de noël » ou le site média « grosses louches d’Ajax ». Tous ces accès en Javascript vers des scripts embarqués ou distants ralentissent vraiment un affichage. Et pour prendre les librairies Ajax par exemple, on les charge parfois juste pour un petit effet de survol sur un lien. On sait aussi que Ajax et les goodies en tous genres peuvent être utilisés à fin de cacher des zones aux visiteurs ou simplement parser du contenu (flux RSS, blogroll automatiques, embed Fanpages Facebook, météo, etc …) qui n’est pas créé par le site même. Je pense qu’il y a peut être une association d’idée à chercher de ce coté là … Le contenu est roi mais si tout le monde se le repasse en boucle, ça affaiblit la pertinence : la lenteur d’une page compterait elle comme un indice ?
Google nous plonge à nouveau dans un flou total avec cette annonce, et dans une situation qui pourrait devenir totalement ridicule.
Google va t-il prendre en compte le temps de chargement des scripts et des images ? Ce temps de chargement dépend uniquement de la connexion de l’internaute. Cela me paraît un peu gros et stupide… l’information que le robot possède reste le temps de réponse du serveur à une requête et c’est sur ce point que l’algorithme peut entrer en compte (je pense). Comme certains le suggéraient, c’est alors les sites hébergés sur les serveurs les plus puissants qui pourraient se voir accorder un privilège, et ceux dont les applications resteraient basiques… Les frameworks et plateformes puissantes largement utilisés (Magento, Drupal, Zend, WordPress et cie) demandent évidemment plus de ressources que le petit site en PHP procédural.
J’ai gagné 3 secondes en changeant récemment de template, pour finir à 1.7 secondes, plus rapide que 80 % des sites selon google. Je pense que le meilleur moyen de réduire ce temps c’est bien de changement totalement la structure du site.
Pour Google la facture énergétique est telle que Google a demandé à devenir fournisseur d’énergie. C’est probablement seulement pour s’auto-alimenter en électricité. L’énergie va voir son coût s’accroître fortement, Google se prépare donc en produisant lui-même (c’est plus intéressant financièrement) sa propre électricité.
Seulement, l’énergie la moins chère est celle que l’on n’utilise pas. Pour Google l’objectif est simple et clair : réduire au maximum ses besoins en électricité tout en continuant à rester performant et à sortir toujours plus d’outils vers toujours plus de monde.
Comme tu l’expliques bien Laurent, Google dicte ses besoins et ses envies sur le Net. S’il est possible de travailler ses outils pour qu’ils soient plus performants et moins gourmands, il est beaucoup plus facile de faire travailler gratuitement les millions de responsables des sites Web sur l’allégement de leurs pages.
En réduisant de 20 ou 30% les temps de chargements des pages, on réduit fortement la charge des serveurs de Google et donc sa facture énergétique. En parlant de ce nouveau paramètre dans leur algo plus le fait de jouer sur la fibre écologique, tout le monde se précipite dessus et Google atteint ses objectifs grâce à nous !
Et nous en tant que webmaster/référenceur/responsable de site, qu’est-ce qu’on doit faire ? Le temps de chargement restera un des paramètres parmi des centaines de l’algo de Google. S’il convient d’y prêter attention, il n’y a pas de raison de trop s’y attarder non plus. La performance du site a un coût. Si le chargement des pages est perçu comme trop lente par les visiteurs, alors c’est un paramètre à travailler pour le ressenti des visiteurs en premier lieu et pas pour Mr Google.
Le Comble comme tu dis c’est quand c’est le script Analytics qui ralenti le script.
Optimisation recommander dans GWT par Page speed:
Limiter le nombre de résolutions DNS
Une seule ressource est diffusée à partir de chacun des domaines des URL suivantes. Si possible, diffusez ces ressources à partir de domaines existants afin d’éviter toute résolution DNS superflue :
* Accéder à l’URLhttp://www.google-analytics.com/ga.js
Enfin!!!
Et bien nous sommes TRES TRES loin du compte. Voici le message que j’ai dans ma console webmaster tools :
En moyenne, les pages de votre site se chargent en 3,3 secondes (dernière mise à jour : 10 avr. 2010). Plus rapide que 51 % des sites.
« au requêtes Web » au lieu de « aux requêtes Web »
@Anonymus: je ne sais pas si Google veut vraiment mettre à genoux Yahoo! par rapport à ce genre d’outils. Mais c’est une option.
@Simon : je pense aussi que Google veut nous obliger à rentrer dans les clous des exigences de sa nouvelle infrastructure Caféine. C’est un peu comme si la route devait être dégagée de tous les cailloux pour laisser s’exprimer la Formule 1.
Il réside aussi des failles qui sont assez rédhibitoires. Je prends pour exemple le fait de fermer les répertoires ou mettre en liens absolus car ça prend des ressources serveur non négligeables.
@Magentix : c’est le problème que j’évoque par rapport à certaines structures comme mettre un système de cache sur un sous-domaine. Le temps d’accès va plomber les résultats, alors que c’est une nette amélioration de l’expérience utilisateur.
@Best-rencontre : tout à fait! Si on veut penser vitesse, il faut que toute la structure soit conçue dans ce sens.
@Immobilier-danger : ah oui j’avais pas pensé à ce paramètre qui est loin d’être négligeable. Pourtant, ça paraît évident que les économies d’énergie à l’échelle d’un index comme Google vont être gigantesques.
Quel bel enfoiré quand même!
@Sacha : il faut que tu passes Analytics en mode asynchrone.
http://code.google.com/apis/analytics/docs/tracking/asyncUsageGuide.html
@Eric : oui mais si tu mets ça en perspective, c’est que dalle 3,3 secondes. Y a que Google pour penser que c’est trop lent.
@Emmanuel0 : merci
« ordonnateur d’Internet » « la loi d’Internet » -> confusion courante entre net et web 😉
C’est gentil, mais je préfère les coquilles par mail car ça n’a aucune espèce d’importance pour ceux qui lisent les commentaires.
Merci
Cela dit, pas capté la remarque. Quelle est la différence entre net et web ?
Le net c’est bien plus que le web.
Au début du net il n’y avait pas de web.
Oui, c’était plus pour souligner le fait que 50% des sites audités s’affichent en plus de 3,3 secondes, soit plus du double du temps recommandé.
De toute manière, pour que cela affecte véritablement le classement, il faut se situer dans les fourchettes extrêmes. Et la, google n’a pas forcément tord en parlant de l’expérience utilisateur, même si ce n’est qu’un argument commercial destiné a te faire penser que c’est pour ton bien, alors que problématique et profits sont clairement de son coté.
Je suis d’accord avec immobilier-danger (qui n’oublie pas d’optimiser sa signature ^^).
Peut on reprocher à Google de faire en sorte d’utiliser moins de ressources?
Les référenceurs sont les premiers à pointer du doigt tout ce qui n’est pas pertinent. Ça ne changera donc rien au discours, si ce n’est un argument de plus à mettre dans la balance. Optimiser le code, c’est pas nouveau.
Pour simplifier : net = réseau (y compris IRC, email) et web = navigateur
Ma terminologie reste correcte car Google prétend bien être le grand ordonnateur d’internet. Il ne s’arrête pas au Web.
Pas grand chose de nouveau sous le soleil… ca fait un paquet de temps que tout bon SEO qui se respecte recommande d’avoir des pages les plus legeres possibles pour un affichage plus rapide (et puis il y avait deja les fameux 100k)
Bon maintenant en plus de ca je vais demander a tous mes clients de faire un petit effort sur le web hosting et la bande passante … bref … pas de panique
Bonjour,
cette peur infligée par Google a quand même du bon : elle m’oblige à passer mon site de son hébergeur gratuit (free, pas très performant c’est le moins qu’on puisse dire en terme de rapidité) à un hébergement professionnel.
Je pense que si ça affecte 1% des résultats en anglais chez les Américains, c’est plus une vague pour faire peur et diminuer la fatigue du crawl chez Google qu’un vrai paramètre dans l’algo…
Tout d’abord, je voudrais dire que je suis ton Blog depuis peu et que tes articles sont toujours intéressant et bien construit, au même titre que ce de Axe-Net. Donc félicitation pour ton travail.
Concernant, ce nouvel indice sur la vitesse des sites web, je trouve en effet que la limite fixée à 1,5 seconde est un peu aberrante. Je m’explique. J’ai réalisé il y a quelque temps de ça, un site très basique pour un artisan, qui souhaitait juste une vitrine rapide pour son activité de poseur de fenêtres sur Lorient. Ce site ne possède aucune fioriture en dehors du WP Cumulus. Les fichiers sont compressés, le cache activé, … Avec PageSpeed, j’obtiens une note de 96/100 et un temps de chargement de 1,2 secondes et pourtant, le Webmaster Tools qualifie mon site de lent.
J’en arrive à la conclusion que, pour l’instant, cette limite n’est que provisoire. En effet, comme tu le dis, beaucoup de sites dépassent allègrement ce temps de 1,5 secondes. Il paraît évident que pour obtenir des temps de chargement inférieur, il faudrait revenir à une architecture « Web 1.0 ». Ceci me paraît infaisable. De plus, avec une telle limite, nous devrions voir une baisse dans les classements pour 90% des sites. Je suis également d’accord sur le fait que certains scripts améliorent grandement l’expérience utilisateur.
Se pose également la question de la pertinence des résultats basés sur la vitesse plus que sur l’intérêt du site en question. Il me semble évident que Google n’a pas d’intérêt à modifier en profondeur son algorithme pour l’instant.
Enfin, à propose de la position dominante de la firme américaine sur Internet, il est vrai que, malgré nos critiques, nous allons encore devoir nous adapter à leurs choix s’il on veut satisfaire nos clients. En pauvre esclaves de Google que nous sommes… :p
@campagne
Tu surestime un peu les americains – Ici rien n’est Gratuit et surtout pas l’hebergement pro. J’en connais un Paquet qui vont devoir mettre la main a la poche pour faire peter un hebergement plus raisonable
Décidément, je viens de découvrir ton blog, et j’aime !
Pour ce qui est de cet article sur google, je suis du même avis que la majorité des gens. Je trouve l’idée de départ bonne, mais je pense que leurs critères sont mal au point pour le moment…
Par ailleurs, comment définissent-ils la vitesse du site, depuis quel pays calculent-ils cette vitesse ? Si ca continue, il va falloir qu’on supprime tous google analytics pour améliorer notre vitesse de chargement et notre ranking sur google… 😀
« Si ca continue, il va falloir qu’on supprime tous google analytics pour améliorer notre vitesse de chargement et notre ranking sur google »
Non mais ca va mieux la depuis un moment avec le script asynchrone non ?
Les futurs conseils en SEO seront peut-être un jour : « Si vous voulez améliorer votre classement, supprimez les services Google de votre site » ARF ! Je rigolerai bien ce jour là…
Mais la va falloir me dire quelle catégorie de personnes se précipitent sur les recommandations Google ?
C est bien les « pros » du SEO qui suivent Google et disent faut faire comme ci et pas comme ça, sinon ton pr va chuter a coup de serp.
Quand aux outils pour verifier ça, permettez moi de rire un bon coup … Et la vitesse de chargement d un site c est vachement relatif comme parametre bien que mesurable facilement. Charge de serveur ? Connexion ? Combien de visiteurs ?
Bref Google reussi encore a faire parler de lui avec du vent …
Bon article Laurent
🙂
pour ajouter ma pierre à l’édifice, je dirai que modifier un gros site ne se fait pas comme cela
quand vous avez plusieurs serveurs SQL
plusieurs frontaux
des sites en plusieurs langues
des centaines de milliers d’annonces, ou d’articles
rendre le site plus rapide ne se fait pas comme cela en une matinée
mais peut représenter plusieurs mois de travail
et occuper un chef de projet pendant longtemps
optimiser des requetes SQL peut prendre un temps fou et demander de grosses sommes d’argent
pour payer les compétences
oui Google installe son dictat et comme tu le dis tout le monde met ses mains sur la couture du pantalon,
mais as t’on le choix lorsque un site d’E-commerce dépend entièrement de google ?
meme des gros sites ne peuvent échapper à l’ogre
Un peu à la bourre mais je me soigne :).
La problématique est encore plus « grave » car de plus en plus de sites utilisent des CMS (Joomla, Drupal mais aussi WordPress). Les webmasters sont « victimes » du code qu’ils utilisent.
J’ai des sites hébergés sur 4 serveurs: 1 dédié et 3 mutualisés.
* les sites PHP sur le serveur dédié tournent autour de 1 sec.
* site « statique » (PHP mais pas de BDD) sur mon mutu anglais est a 0.5sec. Un site wordpress sur le même serveur est là 3.5 secondes.
* site « statique » sur mutu français est là 9 secondes, alors que mon wordpress sur même serveur tourne autour de 6
Chiffres donnés par GWT.
Je pense passé en VDS en France pour voir ce qu’un meilleur serveur apporte comme améliorations sur ces deux sites.
J’ai aussi utilisé Smush it (avec le plugin YSlow sur Ffox) et pour réduire les images en maintenant leur qualité c’est bluffant.
j’avoue que j’ai un peu de mal a saisir comment l’annonce de Google suggère que la vitesse est un signal aussi important que la pertinence
Je suis également de l’avis de Laurent; bien souvent il est très difficile de respecter les standards ordonnés par Google, notamment dans le E-commerce.
Les marqueurs, les pubs, les flash, un peu de javascript, le CSS, les recherches multi-critères qui consomment toujours plus de ressources serveurs… On peut dire qu’on est pas sur une tendance où on revient à la page blanche au design « bloc note »!
Quant à la pertinence des pages, effectivement, je ne vois pas trop le lien… Rapidité d’affichage = contenu?
Et puis, la disponibilité dépend bien sûr du « poids intrasèque » du site… Certes. Mais également de la largeur du tuyau « Bande Passante »! Doit-on se forcer à faire des sites qui se chargent en un éclair, alors que les internautes demandent des expériences toujours plus riches et que les bandes passantes sont de plus en plus importantes?
Quant aux côté Ecolo, je ne peux pas croire que Google et ses millions de serveurs qui tournent à bloc puisse se classer comme « écolo » en faisant brouter des chèvres devant son siège…
Je me demande quelle mesure ça aura, j’ai un site qui a beaucoup d’images donc qui doit forcément être moins rapide que celles de mes concurrents mais bon ce n’est pas la cata non plus pour l’internaute…
Le critére de rapidité est important pour le maintien et la durabilité d’un site ce qui rend primordiale la mise en place de ce filtre de recherche par google, et ceci suivant le niveau de connexion relative au site lui-même