Trouver ce qui limite vraiment votre scène 3D

Votre scène tourne bien chez vous et saccade chez quelqu’un d’autre. Le réflexe est de réduire le nombre de polygones, parce que c’est le seul chiffre que le logiciel de modélisation affiche en gros. La plupart du temps, ce n’est pas le bon levier.

Quatre budgets peuvent brider une scène dans un navigateur. Vous ne pouvez pas deviner lequel serre, et travailler sur le mauvais coûte des jours pour rien. Voici comment trancher.

Pour quelle machine vous optimisez

Avant de mesurer, il faut savoir sur quoi tourne le rendu chez les gens.

Le premier chiffre qu’on trouve est le relevé matériel de Steam, qui donne 8 % pour les GPU Intel intégrés en juillet 2026. Il est exact, et il ne vous concerne pas. Il est mesuré sur une population de joueurs, c’est-à-dire sur les machines qui ne visitent pas votre site.

Deux sources parlent du web. StatCounter donne pour août 2026 49,4 % du trafic mondial sur mobile, 1,5 % sur tablette et 49,1 % sur ordinateur. La moitié des visites arrivent donc sur un SoC, où le GPU fait partie de la puce. Jon Peddie Research prévoit par ailleurs une pénétration des GPU dédiés de 25 % dans les PC sur les cinq prochaines années, ce qui laisse trois ordinateurs sur quatre sans carte graphique.

Environ neuf visiteurs sur dix rendent donc sur de l’intégré. C’est un ordre de grandeur, la donnée de JPR portant sur des livraisons et pas sur le parc qui charge vos pages. Retenez surtout que la machine cible n’est pas la vôtre.

Les quatre budgets

La géométrie. Le nombre de sommets et de triangles à transformer. Ce coût est du côté de la carte, et c’est celui qui profite le plus d’un matériel récent.

Les appels de dessin. Chaque objet distinct demande de préparer un état, de le valider et d’envoyer des commandes. Ce coût est du côté du processeur, il se répète à chaque image, et il ne profite d’aucune carte plus puissante.

Le remplissage. Le nombre de pixels à peindre, qui dépend de la taille du canvas multipliée par la densité d’écran. Un ratio de 2 sur un écran dense quadruple ce travail sans rien changer à la scène.

La mémoire de textures. Ce que les images occupent sur la carte, et ce qui se passe quand ça ne tient plus.

Ces quatre budgets ne se ressemblent pas et ne se corrigent pas de la même façon. D’où l’intérêt de savoir lequel vous limite avant de toucher au modèle.

La méthode, et les trois façons de la rater

Le principe est simple. Vous fabriquez une scène de test, vous ne faites varier qu’un seul axe, et vous regardez à partir de quand la fluidité tombe. Ce qui est moins simple, c’est de mesurer quelque chose de réel. Trois pièges m’ont eu avant que les chiffres veuillent dire quelque chose.

Chronométrer l’intervalle entre deux requestAnimationFrame ne dit rien tant que le budget est tenu, parce que cet appel est cadencé par l’écran. J’ai lu 17,7 ms de cinq mille à trois millions de triangles, ce qui est la fréquence du moniteur et pas le coût de la scène.

Chronométrer autour de render() en appelant gl.finish() pour attendre la carte ne marche pas non plus. Le finish() n’est pas honoré partout, et vous ne mesurez alors que la soumission des commandes. J’ai obtenu 0,1 ms pour trois millions de triangles, ce qui est évidemment faux.

Enfin, vérifiez que le canvas est peint. Deux fois pendant mes essais, je mesurais une scène vide sans le savoir. Un readPixels de quelques pixels au centre suffit à s’en assurer, et il vaut mieux qu’il tourne dans le banc que dans votre tête.

Ce qui reste, et qui est de toute façon la seule chose que l’utilisateur ressent, c’est le nombre d’images réellement délivrées sur quelques secondes.

Ce que ça donne sur un GPU intégré

Une sphère en MeshStandardMaterial, tampon de rendu en 1280 par 720, sur un GPU intégré Intel. Je fais varier le nombre de triangles, puis je découpe le même nombre de triangles en plusieurs objets.

scène	images/s
100 000 triangles, 1 objet	56,1
1 500 000 triangles, 1 objet	56,1
3 000 000 triangles, 1 objet	55,9
6 000 000 triangles, 1 objet	50,2
12 000 000 triangles, 1 objet	23,6
600 000 triangles, 500 objets	56,2
600 000 triangles, 2 000 objets	54,9
600 000 triangles, 5 000 objets	23,7
600 000 triangles, 12 000 objets	9,9

Trois millions de triangles passent sans qu’on les sente. Six commencent à coûter. C’est beaucoup plus haut que ce que je pensais, et beaucoup plus haut que ce qu’on lit.

En face, 600 000 triangles suffisent à tomber à 24 images par seconde s’ils sont répartis en cinq mille objets. La même géométrie, le même nombre de pixels, seulement découpée autrement. L’axe qui casse ici est le nombre de choses, pas la densité du maillage.

Quel symptôme mène à quel levier

Reprenez votre scène et faites varier un axe à la fois, en gardant les trois autres constants.

ce que vous changez dans la scène	si la fluidité remonte, travaillez sur
regrouper les objets en un seul maillage	la fusion par matériau et l’instanciation de ce qui se répète
diviser par deux la densité du maillage	la simplification des modèles et les niveaux de détail
passer le ratio de pixels de 2 à 1	le plafonnement du ratio, quitte à rendre un peu flou sur écran dense
retirer les textures les plus lourdes	les dimensions des images, avant leur nombre

Commencez par le regroupement. C’est l’essai qui m’a le plus surpris, et le seul qui ne demande pas de retoucher les modèles.

Deux réserves honnêtes sur mes chiffres. Ils viennent d’une seule machine, et je n’ai aucun résultat à donner sur la mémoire de textures. Mon banc déclarait jusqu’à 1,5 Go sans que la fluidité bouge, tout simplement parce que three.js n’envoie une texture à la carte qu’à sa première utilisation et qu’un objet unique n’en échantillonne qu’une. Ce test-là ne mesurait rien.

Le banc est dans le dépôt du site, sous scripts/banc-3d. C’est une page qui se mesure elle-même et qui n’a rien à installer, vous servez le dossier et vous l’ouvrez. Les chiffres du tableau sont ceux qu’elle affiche chez moi. Les vôtres seront différents, la forme des deux courbes beaucoup moins.