Dans son dernier billet, Renaud Joly((Je précise que Renaud Joly a ici une mauvaise position due à son billet récent, mais qu’il est malheureusement loin d’être le seul à prendre PageSpeed ou YSlow pour argent comptant, ce billet n’est pas du tout une attaque personnelle…)) profite de la sortie en mars de l’extension PageSpeed pour Chrome((Elle existait déjà pour Firefox.)) pour établir un Top 40 des sites (e-commerce et media) les plus rapides :
Top 40 des sites les plus rapides selon Google PageSpeed http://t.co/XCwSkhE2 #ecommerce #presse #performance
— Renaud JOLY (@renaudjoly) 19 Juin 2012
Sauf que la mesure sur laquelle il se base n’est pas une mesure de performance, mais une mesure de respect d’un ensemble fini de bonnes pratiques. Un site avec une très bonne note PageSpeed peut très bien se révéler plutôt lent quelle qu’en soit la raison, d’une surcharge en contenus multimédia à la présence tôt dans le flux d’un code JavaScript particulièrement bloquant.
Certes, le respect des bonnes pratiques proposées par PageSpeed et YSlow est souvent un bon moyen d’améliorer ses performances — surtout quand on ne connait pas encore bien le sujet —, mais ce ne sont pas les seules choses à prendre en compte, et certaines de ces bonnes pratiques peuvent s’avérer coûteuses et n’offrir qu’un très faible retour sur investissement.
Voici pour illustrer mon point de vu un test comparatif dans WebPageTest((Le test a été réalisé depuis Dulles, en Virginie, ce qui explique la très bonne performance de Amazon et celle bien plus faible de sites plus français ou européens, WebPageTest ne permettant les tests comparatifs que depuis cette instance. Il faudrait faire chaque test individuellement depuis Paris pour avoir une vision plus réaliste des performances perçues en France.)) des 5 premiers et 5 derniers du classement des sites e-commerce réalisé par Renaud Joly. Comme l’indique WebPageTest, 3 chargements sans cache sont faits avec IE8 pour chaque URL et c’est la valeur médiane qui est retenue. J’ai choisi de mettre les URL en .fr et sans sous domaine, donc certaines redirections pénalisent forcément certains de ces sites, à eux de faire mieux :
Voici le résultat sous forme de frise :
Et de façon encore plus parlante, en vidéo au ralenti((J’ai dû retirer Auchan.fr, WebPageTest n’autorisant qu’un maximum de 9 sites pour la vidéo.)) :
On peut constater assez facilement que Leroy Merlin fait mieux que Zalando, Brandalley et Spartoo malgré leurs meilleures notes PageSpeed. Castorama n’est pas non plus très loin. Brandalley et Spartoo sont d’ailleurs une horreur en termes d’expérience utilisateur avec ces popin très intrusives qui empêchent de voir le contenu.
Da Scritch
19 juin 2012
YSlow est un indicateur, mais comme tout indicateur, il ne prend absolument pas en compte certaines métriques ou contraintes propres à la très grande majorité des sites qui ne tournent que sur un seul serveur.
C’est pour ça que j’y ai qu’une confiance très limitée.
Exemples :
-Utiliser un CDN ? Est-ce vraiment utile pour les sites qui utilisent un nombre limité d’images ou qui font attention à leur poids ? Cela peut être une solution overkill pour votre client.
-Mettre les css en haut ? oui, normal, mais il y a-t-il besoin de plusieurs feuilles de styles ? une seule ne suffit-elle pas si elle a un nombre raisonnables de règles ?
-Mettre les scripts en bas ? non ! pas du tout ! utiliser plutôt l’événement onready du DOM, implémentée dans la majorité des frameworks JS. Si le JS était déjà en cache, il est probable que le moteur de votre navigateur démarre le script avant même que le parseur aie fini de travailler le Body. Raconté ici
-Utiliser que GET pour l’Ajax ? hélas non, certains proxys très mal paramétrés (et y’en a) confondent tout et du coup renvoient de mauvaises infos car cachées ! Si l’info est fraîche, non cachable, utilisez un POST. C’est une question de sécurité.
-Mettre un chargeur de js/images/etc… ? Utiliser un chargeur de libs js délayées peut même aboutir à l’excès inverse pour les navigateurs modernes.
-Distribuer les composants entre plusieurs domaines ? oui si vous en avez un sacré nombre à charger et que les navigateurs cibles ne peuvent accepter plus de 4 requêtes en même temps. Sinon, vous risquez la duplication de contenu indexé par les moteurs de recherche, ou qu’ils vous voient en ferme de contenus.
Ce sont des avis tout personnels, et vu la volumétrie de mes clients (surtout soit du mono serveur dédié, soit en client sur application coloué), j’ai voulu m’intéresser à Yslow, mais très vite il était apparu que ces règles sont surtout issues de l’expérience de Yahoo! envers lui-même.
Logique.
Nicolas Hoizey
19 juin 2012
@Da Scritch : merci pour ces réflexions complémentaires.
Nous sommes d’accord pour dire qu’un CDN n’est pas toujours nécessaire, mais le critère principal pour moi pour l’adopter ou non reste l’étendue géographique de la cible de visiteurs. Il faut noter que YSlow a évolué sur ce critère qui n’est plus présent dans le ruleset «Small Site or Blog».
En ce qui concerne le nombre de CSS, c’est dans la règle générale de réduire le nombre de requêtes. Certains sites avec de nombreuses variantes de mises en page peuvent nécessiter plusieurs CSS, mais ce n’est pas le cas le plus courant.
Pour les JS à charger en fin de page, il est clairement possible de faire encore mieux, mais déjà réussir à faire ça n’est pas à la porté de tout le monde, c’est une première étape.
Faire de l’Ajax en POST quand il s’agit uniquement de lire une ressource, c’est quand même bien dommage (et pas REST), les cas où un proxy pas malin est gênant ne sont pas si nombreux, et impactent de toute façon les pages aussi.
Pour le chargeur, il faut évidemment qu’il améliore les perfs, sinon c’est de la sur-qualité… ;-)
Enfin, pour le domain sharding, il faut bien entendu éviter d’en mettre trop — je crois que Yahoo! recommande de ne pas dépasser 3 (sous-)domaines — et les utiliser intelligemment. Le nombre de connexions simultanées des navigateurs étant plutôt de l’ordre de 8 maintenant, c’est déjà bien confortable, le domain sharding reste surtout utile pour les vieux IE.
jpvincent
19 juin 2012
Cela dit, surveiller l’évolution des notes attribuées après chaque mise en production peut être pratique, en complément d’autres chiffres bruts comme le temps de chargement et le start render, car ce sont des données assez faciles a récupérer de manière automatique qui peuvent parfois servir d’alarme lorsqu’ils changent de manière trop drastique
Nicolas Hoizey
19 juin 2012
@Jean-Pierre : effectivement, ils font partie des indicateurs à surveiller quoi qu’il en soit, puisque leur variation peut être un indice d’amélioration ou détérioration de la performance.
Nicolas Hoizey
4 mars 2013
Je découvre un peu tardivement qu’une telle mise au point, limitée à PageSpeed, avait déjà été publiée ailleurs : http://blog.catchpoint.com/2011/12/27/biggest_misconception_about_google_page_speed/
Nicolas Hoizey
12 septembre 2013
Quand on voit ces nouveaux résultats publiés par le JDNet et qu’on s’intéresse au score d’Amazon, on voit bien une fois de plus l’incapacité de Page Speed à prédire la vraie perf…
stephane rios
12 septembre 2013
Entièrement d’accord avec tout ça
A vrai dire le seul indicateur que je trouve pertinent aujourd’hui c’est le Speed Index de WPT …
jpl
14 septembre 2013
@Nicolas,
Comme vous l’avez souligné dans cet article, ces outils (pagespeed, yslow, etc) permettent de souligner le respect (ou non) de certaines bonnes pratiques qui peuvent contribuer à l’amélioration des performances des sites web… Je ne me souviens pas avoir lu que ces outils permettaient de prédire la performance des sites.
jpl
Nicolas Hoizey
16 septembre 2013
@jpl dans l’article du JDNet que j’ai indiqué dans un commentaire très récent, il est explicitement indiqué « Google Page Speed note sur 100 la performance de n’importe quel site conçu pour les mobiles ». J’ai vu de telles mentions en maints endroits.