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.