Chrome accueille Speedometer 2.0 !
Depuis la sortie initiale de Speedometer 1.0 en 2014, les équipes Blink et V8 utilisent ce benchmark comme proxy pour l'utilisation réelle des frameworks JavaScript populaires et ont réalisé des gains de vitesse considérables sur ce benchmark. Nous avons vérifié indépendamment que ces améliorations se traduisent par des bénéfices réels pour les utilisateurs en mesurant sur des sites Web réels et avons observé que les améliorations des temps de chargement des pages des sites populaires ont également amélioré le score de Speedometer.
Pendant ce temps, JavaScript a évolué rapidement, ajoutant de nombreuses nouvelles fonctionnalités au langage avec ES2015 et les standards ultérieurs. Il en va de même pour les frameworks eux-mêmes, et ainsi Speedometer 1.0 est devenu obsolète au fil du temps. L'utilisation de Speedometer 1.0 comme indicateur d'optimisation comporte donc le risque de ne pas mesurer les nouveaux modèles de code activement utilisés.
Les équipes Blink et V8 accueillent favorablement la récente version mise à jour du benchmark Speedometer 2.0. Appliquer le concept original à une liste de frameworks contemporains, de transpileurs et de fonctionnalités ES2015 rend ce benchmark à nouveau idéal pour les optimisations. Speedometer 2.0 est un excellent ajout à notre ensemble d'outils de benchmarking pour les performances réelles.
Performances actuelles de Chrome
Les équipes Blink et V8 ont déjà terminé un premier tour d'améliorations, soulignant l'importance de ce benchmark pour nous et poursuivant notre voyage en nous concentrant sur les performances réelles. En comparant Chrome 60 de juillet 2017 avec le dernier Chrome 64, nous avons réalisé environ une amélioration de 21 % du score total (exécutions par minute) sur un MacBook Pro de mi-2016 (4 cœurs, 16 Go de RAM).
Examinons de plus près les éléments individuels de Speedometer 2.0. Nous avons doublé les performances du runtime React en améliorant Function.prototype.bind
. Vanilla-ES2015, AngularJS, Preact et VueJS ont enregistré une amélioration de 19 % à 42 % grâce à l'accélération de l'analyse JSON et à diverses autres corrections de performance. Le runtime de l'application jQuery-TodoMVC a été réduit grâce à des améliorations de l'implémentation du DOM de Blink, notamment des contrôles de formulaire plus légers et des ajustements de notre analyseur HTML. Des ajustements supplémentaires des caches en ligne de V8 en combinaison avec le compilateur optimisant ont permis d'améliorer les performances à tous les niveaux.
Un changement significatif par rapport à Speedometer 1.0 est le calcul du score final. Auparavant, la moyenne de tous les scores favorisait uniquement le travail sur les éléments les plus lents. Lorsque nous examinons les temps absolus passés sur chaque élément, nous constatons par exemple que la version EmberJS-Debug prend environ 35 fois plus de temps que le benchmark le plus rapide. Ainsi, pour améliorer le score global, se concentrer sur EmberJS-Debug a le plus grand potentiel.
Speedometer 2.0 utilise la moyenne géométrique pour le score final, favorisant des investissements égaux dans chaque framework. Prenons notre récente amélioration de 16,5 % de Preact mentionnée ci-dessus. Il serait plutôt injuste de renoncer à l'amélioration de 16,5 % simplement à cause de sa faible contribution au temps total.
Nous sommes impatients d'apporter de nouvelles améliorations de performance à Speedometer 2.0 et, par conséquent, à l'ensemble du Web. Restez à l'écoute pour plus de démonstrations de performance.