Conseils de performance WebGL pour les sites 3D mobiles

Notez les limites avant d'ajuster la scène. Mesurez le démarrage, le rendu en régime stable, le défilement, l'interaction et le moment où la page devient utile.

Pour la première passe, suivez :

• La taille de transfert du JavaScript et des modèles avant et après la compression
• Le nombre d'appels de rendu, de triangles, de matériaux actifs et la mémoire des textures
• Les tâches du fil principal pendant le chargement et l'interaction
• Le temps de rendu des images pendant que la caméra se déplace, et pas seulement une image au repos
• Le Largest Contentful Paint (LCP), soit le temps nécessaire à l'affichage du plus grand contenu visible
• Les pertes de contexte, les erreurs de mémoire insuffisante et les échecs de chargement d'actifs

web.dev recommande un LCP de 2,5 secondes ou moins pour au moins 75 % des visites de page. Considérez-le comme une cible de chargement de page, et non comme une promesse qu'une scène 3D lourde sera prête à ce moment précis. Affichez d'abord du contenu HTML utile à l'écran, puis chargez la scène.

Testez au moins un iPhone ou un iPad récent, un téléphone Android de milieu de gamme et un appareil Android à faible puissance. Notez le navigateur, le système d'exploitation, la taille de l'écran, le ratio de pixels de l'appareil, le type de connexion et l'état de la batterie. Un GPU de bureau ne peut pas remplacer un GPU de téléphone.

Moins d'appels de rendu donnent généralement plus d'air à une scène WebGL mobile. Un appel de rendu demande au navigateur et au GPU de lier un état et de dessiner un lot; une scène comptant de nombreux petits objets peut donc passer son temps à changer d'état plutôt qu'à dessiner.

Regroupez les objets qui partagent la même géométrie, le même matériau et la même texture. Utilisez l'instanciation pour les maillages répétés comme les cartes, les particules, le feuillage ou les composants de produit. Utilisez des atlas de textures lorsque plusieurs objets peuvent partager une seule texture, afin qu'un changement de texture ne scinde pas le lot.

MDN recommande de regrouper les appels de rendu et donne 1 000 sprites en un seul appel de rendu comme exemple de l'idée. Ne considérez pas 1 000 comme une limite universelle. Analysez la scène que vous livrez et trouvez le point où le temps de rendu augmente sur votre cible la plus lente.

Dans Three.js, inspectez renderer.info.render.calls, les triangles et les points pendant les parcours que les gens utilisent réellement. Un nombre d'appels plus bas n'est utile que si les matériaux, le travail des nuanceurs et la mémoire qui en résultent conviennent à l'appareil.

Le travail sur les textures améliore souvent à la fois le chargement et le rendu. Utilisez des images sources de taille appropriée, des mipmaps pour les textures observées à différentes échelles et des formats compressés pour GPU plutôt que d'envoyer de grandes images non compressées à chaque téléphone.

KTX2 avec Basis Universal est une voie de livraison solide pour un pipeline d'actifs multiappareil. MDN explique que Basis Universal peut convertir vers des formats de texture compressés courants au chargement. Le navigateur a tout de même besoin d'un format GPU pris en charge; testez donc le transcodeur et sa solution de repli sur de vrais appareils.

Ne compressez pas toutes les cartes de la même façon. Les cartes de couleur acceptent plus facilement un format avec perte que les données de normales, de rugosité ou de coordonnées. Une texture qui semble petite sur le réseau peut tout de même consommer beaucoup de mémoire GPU après le téléversement.

Les mipmaps ajoutent environ 33 % de surcharge de mémoire pour les textures carrées, selon les bonnes pratiques WebGL de MDN. Ce coût vaut souvent la peine pour une texture fréquemment observée de loin. Omettez les mipmaps pour une ressource qui n'est jamais réduite, et confirmez le résultat avec un profil de mémoire.

Le chargement progressif rend la page utile plus tôt et évite de demander à un téléphone de décoder toute l'expérience d'un coup. Commencez par une affiche, un petit modèle ou un maillage à faible détail. Remplacez-le par un actif de niveau de détail (LOD) supérieur après la première interaction ou lorsque l'actif est près de la caméra.

Divisez la scène en parcours ou en zones de caméra. Chargez seulement la géométrie, les textures, les animations et les cartes d'environnement nécessaires à la zone courante. Libérez les objets lorsqu'une zone n'est plus utilisée. Supprimer une référence JavaScript ne suffit pas si le moteur de rendu détient encore des ressources de géométrie, de matériau, de texture ou de cible de rendu.

Gardez la première action utile indépendante de la scène complète. Un utilisateur devrait pouvoir lire le titre, ouvrir le menu ou atteindre la section suivante pendant que les actifs 3D continuent de se charger. C'est une meilleure solution de repli qu'un canevas vide avec un indicateur de chargement.

Les écrans mobiles peuvent amener un moteur de rendu à produire beaucoup plus de pixels que la mise en page n'en a besoin. Définissez un plafond de ratio de pixels et abaissez-le lorsque le temps de rendu dépasse votre budget. Gardez la taille CSS du canevas distincte de la taille de son tampon de dessin afin de pouvoir sacrifier de la netteté pour une interaction stable.

MDN recommande de dessiner dans un tampon arrière plus petit comme compromis simple entre qualité et vitesse. Ne multipliez pas le canevas par devicePixelRatio sans plafond en supposant que le résultat est sûr. Les écrans à haute densité peuvent transformer un effet par ailleurs modeste en une importante charge de fragments.

Redimensionnez à partir de la taille réelle en pixels de l'appareil lorsque le navigateur prend en charge device-pixel-content-box, et mettez à jour la fenêtre d'affichage avant de dessiner. Les directives WebGL de MDN indiquent que changer la taille du canevas l'efface; coordonnez donc le redimensionnement avec la boucle de rendu.

Utilisez requestAnimationFrame() pour les mises à jour visuelles et basez la fonction de rappel sur le temps. MDN note que les fonctions de rappel suivent généralement la fréquence de rafraîchissement de l'écran et prévient que l'animation s'exécute plus vite sur les écrans à rafraîchissement élevé lorsque le code ignore l'horodatage de la fonction de rappel.

Mettez le rendu en pause lorsque la page est masquée ou que la scène est hors de la zone visible. MDN précise que les navigateurs mettent en pause la plupart des fonctions de rappel requestAnimationFrame() dans les onglets en arrière-plan, mais votre propre logique de visibilité et d'intersection devrait tout de même arrêter le travail sur les actifs, la physique et le traitement des entrées.

Sortez le travail coûteux du chemin critique. Évitez les requêtes WebGL synchrones comme les appels répétés à getError(), getParameter(), les vérifications d'état des nuanceurs et les lectures par le CPU pendant l'interaction. MDN énumère ces appels comme des blocages synchrones possibles. Recueillez les diagnostics en développement, puis retirez-les ou limitez-les en production.

Utilisez moins de lumières, des chaînes de post-traitement plus courtes et des nuanceurs de fragments plus simples sur les petits écrans. Le travail effectué par fragment peut se multiplier sur l'ensemble du tampon de dessin; réduire à la fois la résolution et le coût des nuanceurs est donc plus efficace que d'en modifier un seul.

Utilisez la détection des capacités et un court échauffement, et non une liste noire de noms d'appareils. Choisissez un palier de qualité selon les fonctions WebGL disponibles, la prise en charge des textures, la taille de l'écran, le temps de rendu mesuré et la pression sur la mémoire. Laissez les utilisateurs passer à un palier inférieur et mémorisez ce choix pour la prochaine visite.

Un modèle de paliers utile ressemble à ceci :

La solution de repli fait partie du design, ce n'est pas un écran d'erreur. MDN recommande de vérifier la disponibilité des extensions et de s'adapter lorsqu'une extension est absente. Appliquez la même logique à WebGL lui-même, aux pertes de contexte, aux téléchargements échoués et aux préférences de mouvement réduit.

Exécutez un parcours de test reproductible sur chaque appareil visé : chargement à froid, premier contenu utile, première interaction avec la scène, mouvement de caméra soutenu, défilement dans la section la plus lourde, passage en arrière-plan et retour, puis rechargement à partir du cache. Capturez une trace de performance et conservez les mesures de la scène à côté.

Comparez les données d'utilisateurs réels avec les données de laboratoire. web.dev explique que CrUX et la surveillance des utilisateurs réels montrent ce que vivent les visiteurs, tandis que Lighthouse aide à diagnostiquer les causes. Un score Lighthouse sur ordinateur de bureau ne prouve pas qu'un GPU mobile peut soutenir la même scène.

Fixez des seuils d'acceptation avant la revue. Par exemple, vous pourriez exiger l'absence de pertes d'images visibles pendant l'interaction principale, l'absence de perte de contexte pendant un parcours de dix minutes, un tampon de dessin plafonné sur les appareils de palier faible et une solution de repli HTML utile lorsque WebGL échoue. Ce sont des décisions de projet, et non des limites universelles de WebGL; consignez donc l'appareil et les conditions de test avec chaque résultat.

• Bonnes pratiques WebGL de MDN : regroupement, compression des textures, mémoire, résolution et directives de compatibilité.
• MDN requestAnimationFrame() : cadence de rafraîchissement, horodatages et comportement en arrière-plan.
• web.dev : Optimize Largest Contentful Paint : cible de LCP mobile, données de terrain, données de laboratoire et diagnostic du chargement.