How to Optimize GLB and glTF Files for Three.js

A smaller file is only an improvement if GLTFLoader can still decode it and the model still looks right on the devices you support. Three.js can load an unusually broad set of glTF compression extensions, but several of them require extra decoder setup. The production workflow is therefore: understand the asset, create a conservative baseline, add one advanced compression feature at a time, and test the exact loader configuration that will ship.

Choose GLB or glTF before optimizing

Prefer GLB when you want one deployable file containing the scene, geometry, animation, and textures. It is harder to misplace a texture or .bin file during a deployment. Choose JSON glTF when separately cached textures or editable text are useful, but preserve every referenced file and its relative path. A lone .gltffile is not necessarily a complete model.

Inspect the model before changing it

Record the original file size, texture dimensions, triangle count, animation clips, morph targets, and material count. Open the original in your Three.js scene and capture a few representative views. Those views are your visual baseline. Texture-heavy assets benefit most from resizing and image compression; geometry-heavy assets may benefit from Draco or Meshopt; a small animated character might need very little processing at all.

A safe OptimizeGLB preset for Three.js

• Enable deduplication and pruning of unused scene data.
• Keep mesh simplification off for the first production candidate.
• Keep Draco and Meshopt off until the matching decoder is configured.
• Cap oversized web textures at 2048 pixels, but keep important labels, UI-like decals, and normal maps at the resolution their use requires.
• Preserve PNG/JPEG for the widest core compatibility, or use WebP at a quality around 80-85 for modern evergreen-browser projects after a visual comparison.

This baseline removes waste without changing the silhouette or requiring an optional geometry decoder. Run it first in OptimizeGLB, then compare the original and output side by side.

Draco, Meshopt, and KTX2 change the loader contract

A Draco-compressed file requires a configured DRACOLoader. A Meshopt-compressed file requires MeshoptDecoder. KTX2 textures require a KTX2Loader, a transcoder path, and a call to detectSupport(renderer) before the model loads. Configure these dependencies before the first request, pin or self-host their runtime files, and make decoder failures visible in the UI.

WebP does not need a WASM decoder in current browsers, but it is still a glTF extension decision. If the same asset must also open in an engine, editor, marketplace, or older embedded webview, validate that destination before making WebP the only texture source.

Do not confuse download size with render cost

Draco can substantially reduce network transfer while adding decode work. It does not automatically lower draw calls, texture memory, or the number of triangles rendered after decoding. Texture dimensions, material count, duplicated meshes, overdraw, and scene structure still matter. Measure download time, decode time, peak memory, and frame rate separately on a representative mobile device.

Handle external resources deliberately

For a .gltf model, serve its sidecars from the same relative layout used by the JSON. Filenames are case-sensitive on many production hosts. Verify MIME types, CORS headers for cross-origin assets, URL encoding for spaces, and cache invalidation. If you receive a missing buffer or texture error, fix the package rather than silently rendering an incomplete scene.

Three.js release checklist

1. Run the optimized asset through the Khronos glTF Validator.
2. Load it with the exact production Three.js and decoder versions.
3. Exercise every animation, morph target, camera, and material variant.
4. Compare silhouettes, normals, transparency, and texture detail.
5. Test a cold load and repeat load on desktop and mobile.
6. Keep the source asset and conservative output available for rollback.