Performance des navigateurs : regardons ce que les benchmarks classiques mesurent

Lorsque l’on parle de vitesse, il faut trouver un moyen de mesurer de manière facile et consistante les différents navigateurs du marché pour les comparer entre eux. La notion de benchmark est ainsi peut-être aussi vieille que celle de l’industrie du logiciel. La plupart des gamers sont par exemple habitués à cet exercice de comparaison de leur dernière carte graphique afin de vérifier si l’achat d’une double carte graphique montée en SLI va enfin leur permettre de gagner ces 3 FPS qui les séparent du saint graal de la performance absolue. ;-) Mais cela change-t-il vraiment fondamentalement leur expérience de jeu ? Tenter de gagner quelques images par seconde sur un jeu grâce à un nouveau GPU est-il intéressant si le goulot d’étrangement vient d’autre part comme du moteur physique qui sature le CPU par exemple ? Bref, un benchmark teste souvent de manière intéressante une partie spécifique d’un logiciel ou d’une machine mais il faut ensuite avoir un peu de recul pour analyser sereinement ce que cela implique au niveau global et dans un scénario réel. Un benchmark n’est donc là que pour mesurer une partie précise. C’est ensuite à vous d’évaluer si cette mesure est importante pour votre client, vos développeurs et pour vous.

Dans le monde des navigateurs, cette discipline existe aussi et doit être analysée avec les mêmes égards.

Il fait donc suite à un article précédent où nous découvrions ensemble la manière dont les sites web classiques sollicitent les différentes couches d’un navigateur. Je vous invite à le lire ici si ce n’est déjà fait : Performance : essayons de comprendre comment les sites web sollicitent les différentes parties d’un navigateur (ou la genèse de l’architecture d’IE9)

Nous allons reprendre le même diagramme présentant les 11 modules d’IE et voir comment les benchmarks classiques attaquent ces modules.

Celtic Kane
Celtic Kane est généralement vu comme étant le premier benchmark JavaScript. Il fut créé à l’origine en 2006 par un développeur web (Sean Patrick Kane) et devient populaire une fois qu’il fut intégré sur Digg.com. Celtic Kane s’appuie sur 8 cas de tests basiques exécutés 1 seul fois et mesurés en millisecondes. Ce benchmark dit se concentrer sur le moteur JavaScript et sur les performances de l’accès au DOM. Cependant, les tests censés stresser le DOM dans ce benchmark ne le mesure pas vraiment.

Si l’on reprend notre diagramme des 11 modules successifs d’IE, uniquement le module JavaScript est donc mesuré.

WebKit SunSpider
WebKit SunSpider est certainement le plus connu des benchmarks et s’est donc attiré une attention toute particulière de l’industrie. Ce benchmark a été développé par l’équipe WebKit d’Apple. Leur but était de mesurer les performances du moteur JavaScript. Cependant, le test SunSpider se concentre sur les performances du moteur JavaScript à travers des jeux de tests très particuliers. Il y a en effet 26 jeux de tests qui essaient de mesurer les performances de certaines parties précises de JavaScript comme les opérations sur les tableaux, les opérations mathématiques et les expressions régulières par exemple. Ainsi, le test SunSpider travaille sur moins de 10% de l’ensemble des APIs disponibles depuis JavaScript. Par ailleurs, plusieurs d’entre eux exécutent en boucle le même code des milliers de fois. Cette approche n’est donc pas très représentative des scénarios du monde réel et a tendance à favoriser certains moteurs JavaScript.

Reconnaissons malgré tout que ce test a permis de faire bouger les consciences et de relancer une saine concurrence entre les navigateurs. Nous ne manquerons d’ailleurs pas de communiquer sur les progrès mesurés par ce benchmark sur notre nouveau moteur de script Chakra. A vous ensuite de faire la part des choses.

Google V8
Google’s V8 fut conçu par Google pour améliorer son propre moteur JavaScript V8. Ce benchmark mesure donc naturellement le module JavaScript d’un navigateur. Les mesures se basent sur des scénarios complexes tels que l’analyse d’une simulation de l’ordonnanceur de threads des OS, des opérations de cryptographie et des calculs de ray tracing en JavaScript. Bien que particulièrement bien conçu, le benchmark V8 n’utilise pas des jeux de tests représentant les modèles de développement classiques que l’on retrouve chez la plupart des développeurs JavaScript. Par ailleurs, la plupart des tests sont en fait des adaptations de tests existants écrits à l’origine dans d’autres langages tels que Smalltalk.

A nouveau ce benchmark reste malgré tout intéressant pour mesurer ces opérations très spécifiques. A voir maintenant si vos besoins tournent autour de ces opérations mathématiques très complexes.

Mozilla Dromaeo
Mozilla’s Dromaeo est probablement le benchmark JavaScript/DOM le mieux conçu aujourd’hui. Il fut écrit à l’origine par John Resig de la fondation Mozilla afin d’aider au développement de Firefox. C’est outil est particulièrement pertinent pour les concepteurs de navigateurs qui ont besoin de mesurer les performance de chacune des APIs. Par ailleurs, en plus de tests purement tournés vers le moteur JavaScript et l’accès au DOM, Domaeo mesure d’autres zones supplémentaires comme les framework jQuery ou Prototype ainsi que les sélecteurs CSS.

Flying Images
Notre démo Flying Images proposée lors de l’une de nos premières Platform Preview d’Internet Explorer 9 est devenue malgré nous une sorte de benchmark mesurant l’accélération matérielle du GPU sur le web. Je vous en avais déjà parlé dans cet article où l’on y comparait les performances d’autres navigateurs (IE8, Chrome 4.1, Safari 4 et Firefox 3.6 à l’époque).

Notre but initial avec cette démo “Flying Images” était de montrer l’impact que pouvait avoir le GPU sur des sites web HTML4 d’aujourd’hui et de pas en créer un benchmark. Maintenant, je peux comprendre que vu que nous affichons le nombre d’images par seconde (FPS), la tentation était grande de s’en servir comme benchmark. Malgré tout, cette démo représente assez bien les modèles de développement classiques que l’on retrouve dans les applications AJAX. Elle utilise les standards actuels HTML4, du code JavaScript et du CSS pour animer les images par code sur l’ensemble de l’écran toutes les 1/60ième de seconde (l’idée étant de viser le rendu dit “temps réel” sur un écran à 60 Hz). Cette démo manipule le DOM, change certaines propriétés CSS et entraine du coup l’ensemble de la page à passer à travers le processus de mise en page.

Comme on peut le voir ici, elle stresse bien plus de modules du navigateur que les benchmarks précédents :

FishIE Tank
La démo FishIE Tank fut introduite avec l’arrivée de la 3ème version de la Platform Preview apportant le support de la balise canvas, le tout accéléré matériellement. Cette démo à nouveau fut considérée par certains blogueurs et d’experts technologique comme un benchmark de part son côté très visuel et via la présence à nouveau du compteur de FPS. FishIE Tank mélange à la fois les modèles de développement traditionnels HTML avec la balise HTML5 canvas. On utilise ainsi le canvas d’HTML5 pour animer les poissons sur l’ensemble de l’écran à l’aide d’un code JavaScript gérant aussi les collisions. Des choses plus traditionnelles comme l’innerHTML sont utilisées pour afficher le compteur FPS indiquant le nombre d’images par seconde. Cette démo voulait montrer les modèles que l’on risque de voir émerger bientôt mêlant pratiques traditionnelles actuelles (HTML4) et l’insertion de quelques nouveautés d’HTML5.

Les mêmes blocs sont donc sollicités que la démo précédente :

Psychedelic Browsing
La démo Psychedelic Browsing a déjà été vue plus de 500 000 fois sur les 5 dernières semaines depuis que la 4ème mouture de notre plateforme technologique d’IE9 fut présentée en Aout. Elle s’occupe de faire tourner une roue chromatique aussi vite que possible à l’écran. Le but était de stresser une pratique classique de développement HTML5 utilisant du JavaScript et le DOM pour dessiner au sein d’un canvas tout en jouant un élément audio HTML5 en tâche de fond. Nous avons en effet vu ce modèle de développement émerger au cours des 6 derniers mois au fur et à mesure de l’adoption grandissante de la balise canvas par les développeurs. Cela peut donc donner une tendance vers laquelle les futures applications web pourraient se diriger.

Conclusion
Nous pensons que l’écriture d’un navigateur rapide pour tous implique de commencer par comprendre quels sont les modèles utilisés dans les applications du monde réel consommés par l’ensemble des utilisateurs. C’est alors que l’on peut construire l’architecture du navigateur autour de ces modèles. Vous ne pouvez donc pas construire un navigateur rapide pour tous en vous contentant uniquement de l’optimiser autour de benchmarks connus.

De la même manière, vous ne pouvez pas vous reposer uniquement sur les résultats de performance à des benchmarks pour en déduire le niveau global de performance d’un navigateur. Comme de manière assez proche, le test ACID3 ne représente pas grand chose du niveau de couverture total du support d’HTML5, CSS3 ou SVG. Ce n’est donc pas parce que vous obtenez la note maximale (100) que vous supportez pour autant plus ou mieux l’ensemble des spécifications HTML5 qu’un navigateur ayant un peu moins.

Par contre, lorsque ces benchmarks sont utilisés en tant qu’outil par les développeurs pour comprendre les implications engendrées par leurs modifications de code et pour les aider à améliorer certains zones spécifiques, ils font pleinement sens. C’est d’ailleurs tout là que se trouve leur valeur.

L’ensemble de l’industrie doit donc faire attention à ne pas perdre de vue l’essentiel : les scénarios d’usage réels de nos utilisateurs sur les technologies d’aujourd’hui et sur les scénarios HTML5 de demain.

David Rousset
Microsoft France