Analysons un peu l’annonce

Je disais donc que Google venait d’annoncer que la vitesse de la page allait être prise en compte dans les calculs de pertinence de résultats. C’est ce qu’on entend et lit à répétition sur divers blogs et sites internet d’information. Pour autant, l’annonce, sous cette forme, manque cruellement de précision.

La vitesse d’une page est une notion qui n’a presque aucun sens si on ne lui apporte pas un peu de nuance : une première distinction que l’on peut faire concerne la différence entre la vitesse côté serveur et côté client. Pour le serveur, la vitesse de la page correspond à la vitesse à laquelle la requête HTTP va être analysée, la page générée, renvoyée et le temps que le volume de données soit reçu par le client. Si on s’intéresse maintenant au “côté client”, on aura le délai nécessaire pour que la page soit reçue (l’aspect réseau est donc à cheval entre les deux côtés) et le temps qu’il faudra pour que la page soit interprétée et affichée par le navigateur. Pour le client, une page affichée ne correspond que très rarement à un seul aller-retour entre son poste et le serveur : les feuilles de styles, fichiers sources javascript et images sont autant de requêtes qui devront être traitées.

Il serait bon de savoir ce que les crawlers de Google seront effectivement en mesure d’analyser : les mesures de vitesse seront-elles empiriques ou théoriques ? Quels facteurs parmi ceux que je viens de citer seront concernés ? La vitesse pour google est-elle la même que pour le visiteur, le vrai, humain ?

Ce qui va changer

D’après les chiffres que j’ai pu lire dans l’annonce officielle, le paramètre vitesse affecte environ 1% des résultats de recherche (sur l’index actuel, c’est à dire, avec les pages telles qu’elles sont aujourd’hui). La pondération de ce paramètre sera d’ailleurs particulièrement faible en comparaison des critères de pertinence du contenu.

Le bon côté, c’est qu’il est probable que les pages immondes au possible des gros sites corporate (allez, au hasard, orange.fr, voyages-sncf.com, …) subissent à un moment ou à un autre un remaniement vers le mieux, grâce à l’orgueil blessé de leurs concepteurs ; autant dire que pour l’instant, malgré les nombreux reproches des utilisateurs, rien n’a bougé, je n’ai donc pas beaucoup d’espoir sur ce point.

Ce que j’aime beaucoup moins, ce sont les nombreux risques de dérives portées par les bouchers de l’optimisation : on coupe dans la conception, le code et on nettoie par le vide, autant que possible, pour ne garder que des bouts. C’est le point essentiel de mon article, et j’y reviens dans un instant.

Enfin, l’utilisateur sera peut-être gagnant si les développeurs s’emploient effectivement à améliorer les performances de leurs pages, mais le grand gagnant est -comme toujours- Google. Je pense vraiment que ce nouveau choix technique a pour but d’inciter les développeurs à effectivement améliorer “la vitesse des pages”, et ces petites améliorations qui s’accumulent, représenteront un gain de ressources et d’immobilisation de leurs serveurs qui ne se néglige pas.

Le code sacrifié sur l’autel du grand G.

On est maintenant au fond de mon propos : pour de multiples raisons j’ai peur que cette annonce entraîne des pratiques contre-productives pour la majorité d’entre nous (je veux dire, nous utilisateurs d’internet, pas seulement nous les développeurs web).

Pour aider les développeurs à optimiser leurs pages pour gagner des micropoints auprès des robots, de nombreux outils d’analyse et de benchmarking sont à notre disposition. Ceux-ci apportent de nombreux conseils,  mais qui, définitivement, ne nous concernent pas tous. C’est au concepteur de connaître le véritable intérêt des différents critères d’analyse proposés par ces outils. Pour donner un petit exemple : Yahoo! Slow suggère d’utiliser des Content Delivery Network (côté Google Page Speed on est un peu plus sobre est on suggère de “paralléliser les téléchargements grâce à l’utilisation de plusieurs domaines”). Je devrais faire quelques tests pour compléter ma connaissance du sujet, mais ma première réaction est “Mes problèmes ne sont pas ceux de G. et/ou Y!” : à l’échelle de ce modeste site, par exemple, ai-je un intérêt à doubler mon parc de serveurs (j’en ai un seul), simplement pour transférer plus rapidement les quelques images et feuilles de styles qui composent la page ?

Par ailleurs, cette règle (màj : paralléliser les téléchargements grâce à plusieurs domaines) contredit celle qui me suggère de minimiser le nombre de domaines utilisés pour réduire le nombre de requêtes DNS…

Le pire n’est pas proposé par ces outils : il y a le concept du tuning de code, prôné par exemple par HTMLminify. Le principe est assez simple : minimiser au possible le poids de la page, d’une part en supprimant les caractères inutiles (espaces, commentaires, etc), et d’autre part en s’affranchissant des règles syntaxiques et des standards, en supprimant par exemple les balises les plus élémentaires et qui n’ont pas d’impact direct sur l’affichage : DocType, balises de fermantes et même la balise <html> !

D’une part, on sacrifie la qualité du code : lisibilité, facilité de maintenance, debbugage, etc. Ces problèmes n’existent plus si on adopte une stratégie de mise en production avec pré-compilation, ces optimisations extrêmes n’apparaissent plus sur le code manipulé en développement.

Par contre, d’autres soucis bien plus dangereux ne disparaissent pas. On casse le caractère standard du code, au risque de rendre la page illisible par de nombreux navigateurs. On se dira qu’à priori on peut se débrouiller pour obtenir la même interprétation de la part des différents navigateurs. C’est sans compter sur la multiplication des nouveaux terminaux mobiles ; et il est fort possible que les prochains navigateurs adoptent des stratégies d’analyse plus proches des standards, et que les résultats deviennent très surprenant à l’avenir. Je vous laisse imaginer les coûts de maintenance. On peut ajouter les navigateurs accessibles qui utilisent de nombreuses informations contenues dans la page pour permettre à une personne souffrant d’un handicap de consulter un site internet, ces informations ne sont souvent pas utilisées sur d’autres navigateurs.

Pour les autres outils d’analyse, comme les parsers XML, on peut directement abandonner toute chance de s’en sortir.

Enfin, ces optimisations permettent de minimiser le poids de la page, et donc le temps de transit sur le réseau. Par contre, une fois la page arrivée chez le client, le résultat devient clairement contre-productif : le navigateur devra interpréter la page en Quirks mode, et utilisera nettement plus de ressource pour essayer de nettoyer, corriger et transformer le code de manière à le rendre conforme aux règles syntaxiques : c’est du temps perdu pour que la page soit affichée.

La discussion à se sujet est déjà en cours sur Sitxpress, où le commentaire de mon ami Adrian reformule mon propos.

Nous avons donc réfléchi au point de vue des développeurs, des moteurs de recherche, des utilisateurs. Il reste encore deux catégories d’acteurs qui ne doivent pas être oubliées. D’une part, les chercheurs du W3C : ceux-ci utilisent toute leur énergie pour standardiser le web, le rendre accessible et le faire évoluer. Sacrifier les standards, c’est aussi un peu sacrifier leur travail. D’autre part, pensons aussi aux concepteurs des moteurs utilisés par nos navigateurs. L’analyse, l’interprétation et l’harmonisation du code HTML non standard (et pire, ne respectant pas les règles syntaxiques) représente une montagne de travail de conception et de développement, c’est à dire : un gaspillage d’argent et de ressources qui ne seront pas destinées à l’implémentation de nouvelles fonctionnalités comme les très attendues nouveautés de standard HTML 5.

Ma conclusion sera aussi simple que brève : optimiser, c’est important, mais pas au point de faire n’importe quoi. J’en profite pour faire un peu d’auto-promo, car c’est le discours que je tiens dans mon article sur l’optimisation d’une application en PHP 5 dans le magazine PHP Solutions de ce moi-ci.

Màj : Merci à Agathe, d’Open21 pour le relai de l’information !