Comment optimiser un fichier GLB pour le web

Comprendre ce qui rend un GLB lourd

Le poids du fichier n’est qu’une partie du coût. Le navigateur doit télécharger, décoder, transférer vers le GPU puis afficher géométries et textures. Une image JPEG compacte peut occuper beaucoup plus de mémoire une fois décodée ; de nombreux petits meshes et matériaux multiplient aussi les changements d’état et les draw calls.

• Géométrie : sommets, indices, morph targets et attributs.
• Textures : dimensions, canaux, nombre et format.
• Scène : meshes, matériaux, lumières et animations.
• Runtime : DPR, éclairage, ombres, appareil et viewer.

Mesurer avant d’optimiser

Conservez un fichier de référence et mesurez sur une connexion et un appareil représentatifs. Relevez le poids transféré, le délai avant le premier rendu, la stabilité de la cadence d’image et la mémoire approximative. Un budget utile dépend du téléphone, du viewer, de l’éclairage, des animations et du niveau de détail attendu : un seuil universel serait trompeur.

Le validateur glTF détecte les erreurs de structure ; les outils de développement du navigateur montrent réseau, mémoire et temps CPU. Comparez une modification à la fois pour savoir ce qui améliore réellement l’expérience.

Réduire la géométrie sans dégrader la silhouette

Décimez d’abord les zones peu visibles, les surfaces planes sur-segmentées et les détails qu’une normal map peut restituer. Préservez les contours, les articulations et les éléments proches de la caméra. La compression géométrique réduit le transfert, mais elle ne retire pas les triangles que le GPU devra finalement traiter.

• Supprimer objets masqués, doublons, sommets isolés et attributs inutilisés.
• Fusionner avec discernement les objets partageant un matériau.
• Vérifier les normales, UV et transformations avant export.
• Comparer le rendu à la distance réelle d’utilisation.

Optimiser textures, résolution et formats

Dimensionnez chaque texture selon sa taille maximale à l’écran. Une texture 4K n’est pas automatiquement utile sur un objet affiché en quelques centaines de pixels. Réduisez les canaux inutiles et regroupez, lorsque le pipeline le permet, occlusion, roughness et metallic.

JPEG convient aux images opaques avec variations continues ; PNG aux aplats ou à l’alpha quand la fidélité sans perte est nécessaire ; WebP peut réduire le transfert avec un bon support navigateur ; KTX2 vise une texture GPU compressée et peut réduire mémoire et bande passante, au prix d’un pipeline et d’un décodage spécifiques. Testez toujours le résultat visuel.

Réduire matériaux, meshes et draw calls

Deux fichiers de même poids peuvent avoir des performances très différentes. Chaque matériau ou groupe de primitives peut entraîner un draw call. Réutilisez les matériaux identiques, évitez les variations presque imperceptibles et envisagez un atlas lorsque cela simplifie réellement la scène sans sacrifier la qualité ou la maintenance.

Nettoyer les animations

Supprimez les pistes vides, les clés redondantes, les clips non livrés et les bones sans influence. Réduisez la fréquence d’échantillonnage seulement après comparaison visuelle : une animation mécanique tolère parfois une réduction différente d’un visage ou d’un tissu.

Draco, Meshopt et coût de décompression

Draco et Meshopt peuvent réduire la géométrie transférée. Ils ne corrigent ni un maillage inutilement dense, ni des textures surdimensionnées, ni trop de matériaux. Leur décompression consomme du CPU et nécessite le décodeur correspondant dans le viewer ; sur un appareil modeste, le fichier le plus petit n’est donc pas toujours celui qui apparaît le plus vite.

Vérifiez que le viewer cible prend en charge l’extension choisie, mesurez le temps de décodage et conservez un pipeline reproductible.

Préparer et exporter depuis Blender

Travaillez sur une copie, appliquez les transformations lorsque le rig et le pipeline l’autorisent, purgez les données inutilisées, contrôlez les UV et inspectez chaque matériau. À l’export GLB, incluez uniquement les objets et animations nécessaires. Rouvrez le fichier exporté : le viewport Blender n’est pas une validation du résultat web.

Tester sur mobile, en mémoire et dans un vrai viewer

Testez au moins un appareil proche du bas de votre cible, avec les paramètres réels du viewer. Surveillez le premier affichage, la réactivité des contrôles, les pics lors du décodage et le comportement après plusieurs chargements. Les textures embarquées restent à contrôler : leur compression dans le GLB ne représente pas leur empreinte GPU.

Un modèle public DevXR illustre le rendu dans un navigateur. Il s’agit d’une démonstration du viewer, pas d’une preuve de compression ni d’un benchmark.

Erreurs fréquentes

Compresser sans mesurer, conserver toutes les textures en 4K, multiplier les matériaux pour de faibles variations, tester uniquement sur une station de travail et considérer le poids du GLB comme unique indicateur sont les erreurs les plus courantes. Ajouter Draco à la fin d’un pipeline ne remplace pas les décisions de modélisation.

Checklist avant publication

Validez le fichier final, pas seulement la scène source.

• Silhouette et niveau de détail vérifiés à la distance cible.
• Objets, attributs, matériaux et animations inutiles retirés.
• Résolutions et formats de textures justifiés.
• Extensions de compression prises en charge par le viewer.
• Chargement, mémoire et interaction testés sur mobile.
• Rendu contrôlé dans le viewer et l’iframe réellement utilisés.

Tableau de décision pour les textures