Budget de performance Three.js et React Three Fiber

Problème

Une scène fluide sur une machine de développement peut devenir inutilisable sur mobile : trop d'appels de rendu, textures lourdes, rendu continu inutile, DPR excessif ou ressources GPU jamais libérées.

Démarche mesurable

1. Définir les appareils cibles et une qualité de repli avant l'effet visuel.
2. Mesurer FPS, temps CPU/GPU, appels de rendu, triangles et mémoire avec renderer.info, les DevTools et Spector.js.
3. Profiler une seule variable à la fois sur la scène réelle, pas seulement sur une démo vide.
4. Réduire d'abord les appels de rendu et le fill-rate, puis la géométrie et le poids réseau.
5. Retester le chargement initial, l'interaction, l'arrière-plan et plusieurs changements de page.

Budget de départ

• Viser quelques centaines de draw calls ; considérer 1 000 comme plafond d'alerte, pas comme objectif.
• Une géométrie répétée devient une InstancedMesh ou <Instances> ; des objets statiques compatibles sont fusionnés.
• Utiliser <Detailed>/LOD pour diminuer le détail avec la distance.
• Limiter le DPR selon l'appareil ; dégrader ombres, post-traitement et résolution avant de casser l'interaction.
• Compresser les GLTF avec glTF Transform/Draco et convertir les textures adaptées en KTX2/Basis.
• Dimensionner les textures à l'usage réel : une texture 1024×1024 décompressée occupe déjà plusieurs Mo côté GPU.

React Three Fiber

• Une scène au repos utilise <Canvas frameloop="demand">; après une mutation impérative, appeler invalidate().
• Dans useFrame, muter les refs avec delta; ne pas déclencher setState à chaque image.
• Réutiliser géométries, matériaux et objets mathématiques au lieu de les recréer dans la boucle.
• Drei fournit notamment Instances, Merged, Detailed, AdaptiveDpr, PerformanceMonitor, Bvh, BakeShadows et Preload.
• Preload peut compiler les matériaux avant leur première apparition et réduire le à-coup de première vue.

Gate avant livraison

• Aucun rendu continu lorsque la scène est immobile sans raison documentée.
• Pas de hausse durable de renderer.info.memory après plusieurs montages/démontages.
• Test sur appareil bas/milieu de gamme, économie d'énergie et préférence de mouvement réduit.
• Un fallback 2D ou statique conserve le contenu et l'action principale si WebGL échoue.
• L'effet 3D ne dégrade pas les Core Web Vitals ni l'accès clavier au contenu.

Ressources sélectionnées

• Three.js — Optimize Lots of Objects — démontre que fusionner des milliers de géométries réduit radicalement les draw calls.
• R3F — Scaling performance — rendu à la demande, instancing, LOD et concurrence React.
• R3F — Performance pitfalls — règles de boucle de rendu et réutilisation d'objets.
• Drei — abstractions R3F, dont un groupe dédié à la performance.
• glTF Transform et glTF Report — diagnostic et optimisation des assets.
• Spector.js — capture et inspection des commandes WebGL.

Origine et limites

Les catalogues awesome-threejs et awesome-webgl servent ici à découvrir des outils. Les recommandations normatives viennent ensuite des documentations Three.js, R3F, Khronos et MDN. Une valeur de budget doit toujours être recalibrée sur le produit et les appareils cibles.