Même Mac, cinq navigateurs, cinq scores

Un Mac Studio équipé d’un M4 Max a obtenu 10 630 à notre benchmark dans un Apple Store. Le MacBook Pro qui nous servait de point de comparaison — un M2 Max plus ancien — avait obtenu environ 12 900 à la maison. La puce plus récente et plus grosse perdait de 18 %, et les suspects évidents (36 Go de RAM contre 96, une machine de démonstration au repos contre une machine de développement en plein travail) n’expliquent rien de tout cela.

Nous avons donc fait passer une seule machine — ce même M2 Max, même écran, même après-midi — dans cinq navigateurs :

Même silicium, même écran, un facteur deux entre le meilleur et le pire. Les chiffres par scène sont encore plus étranges que les totaux. Notre scène de raymarching, Chrome liquide, tenait 25 523 unités dans Safari et 5 622 dans Firefox — sur le même GPU. Cercles Canvas 2D : 64 476 dans Opera, 9 960 dans Firefox. Notre scène de physique CPU tournait 29 % plus vite dans Safari que dans n’importe quel navigateur Chromium, parce que JavaScriptCore apprécie ce code davantage que V8.

Et le résultat du magasin s’est révélé être la même histoire sous un autre costume. Dans Safari, un M2 Max tenait 25 523 unités du raymarcher — mais le M4 Max du magasin en tenait 6 222, et un M5 Pro 2 628. Même navigateur, même scène, et des GPU plus récents et plus rapides quatre à dix fois moins bons. Le shader contenait une boucle de 180 itérations, et une certaine combinaison des générations de GPU récentes et du compilateur Metal s’étranglait dessus, là où les plus anciennes ne bronchaient pas. Cette scène ne mesurait plus le débit de fragments. Elle mesurait la chance du compilateur.

Ce qu’un benchmark de navigateur mesure honnêtement

Le nombre que produit ce site n’est pas une note de puce. C’est la mesure de toute la pile que vous utilisez réellement : silicium, pilote, compilateur de shaders, moteur JavaScript, rastériseur canvas, compositeur. C’est une qualité — c’est la performance que vous obtenez en ouvrant une page — mais cela signifie que deux règles comptent quand vous comparez :

Comparez au sein d’un même navigateur. Un score obtenu dans Safari et un score obtenu dans Chrome mesurent deux piles différentes qui se trouvent partager une puce. Notre classement des meilleurs scores indique depuis un moment le navigateur sur chaque ligne ; désormais, la fiche de résultat affiche aussi la médiane du même matériel par navigateur, dès qu’il y a assez d’échantillons.

Un benchmark ne devrait pas amplifier les bizarreries de la pile. Que la pile fasse partie de la mesure, c’est honnête. Qu’une scène s’effondre d’un facteur 10 parce qu’un compilateur n’aime pas la forme d’une boucle ne l’est pas — c’est le benchmark qui est fragile, et c’est à nous de le corriger.

Ce qui a changé dans le benchmark 2.3.0

Le raymarcher dessine désormais par petites passes. Au lieu d’un seul shader qui boucle jusqu’à 180 échantillons, Chrome liquide accumule des passes répétées de quatre échantillons — mêmes positions d’échantillonnage, même travail total, arithmétique inchangée au chiffre près. Une boucle de quatre itérations est exactement le genre de shader que tous les moteurs compilent bien ; la prochaine visite en magasin dira si cela ramène les GPU Apple les plus récents sur la tendance de leur débit de fragments. Firefox, lui, n’a pas bougé — 5 622 aussi avec le nouveau shader — parce que son coût se trouve dans le travail de chaque échantillon, pas dans la boucle qui l’entoure, et corriger cela changerait la charge de travail elle-même.

Un seul budget soutenu pour tous les écrans. Les horodatages vsync réels se révèlent plus désordonnés que le modèle bien rangé livré avec la 2.2.0, et les machines branchées sur un écran à fréquence fixe avaient discrètement droit à un budget soutenu par image ~9 % plus souple que les portables à synchronisation adaptative. Tout le monde répond désormais à la même moyenne tronquée de 17,5 ms.

Les démarrages à froid ne produisent plus n’importe quoi. Les premiers tests dans un navigateur tout juste lancé étaient brutaux : un Mac de démonstration en magasin a obtenu 77, puis 8 553 quelques minutes plus tard ; nos propres premiers tests Safari à la maison affichaient 304 et 1 149 avant un 11 443. Trois correctifs : le benchmark vérifie désormais si votre machine est occupée avant d’y consacrer trois minutes, attend scène par scène que passent les saccades de compilation des shaders de la première visite, et accorde à une scène qui n’a rien mesuré une tentative de plus à la fin du test si la machine s’est calmée. Rien n’est inventé — une nouvelle tentative n’est qu’une seconde mesure.

Les marqueurs disent désormais la vérité. Un test dont chaque scène avait mesuré, mais où un niveau n’avait pas pu être confirmé sur trois fenêtres d’affilée, était auparavant ramené au plancher et entièrement exclu du classement. Nos données de production montrent que ces niveaux se situent environ 13 % en dessous de ce que mesurent les appareils stables — c’est du matériel en difficulté qui l’avoue honnêtement, pas un chiffre truqué —, ils sont donc désormais publiés avec un marqueur, et chaque marqueur de scène dit exactement laquelle de trois choses s’est produite.

Et les résultats voyagent. Copier le lien emballe désormais tout le résultat — score, charges par scène, temps d’image, marqueurs — dans le lien lui-même. Rien n’est envoyé ; ouvrez-le n’importe où et il s’affiche en lecture seule. Si vous testez un jour un ordinateur qui ne vous appartient pas, vous n’aurez plus besoin de photographier l’écran. Nous savons. Nous avons photographié beaucoup d’écrans.

Les scores de la 2.3.0 ne se mélangent jamais avec ceux des versions précédentes, le classement repart donc de zéro. Si vous voulez la version longue du fonctionnement de la mesure — les fenêtres de temps d’image, l’échelle de charge, ce qui peut invalider un test —, la page de méthodologie contient tout. Ou lancez simplement le test : il dure environ trois minutes et vous prévient désormais d’emblée si votre machine n’est pas d’humeur.