How to optimize a GLB file for the web

Understand the real cost of a GLB

File size covers transfer, not the whole rendering cost. The browser still decodes data, uploads it to the GPU and draws the scene. A compact JPEG can expand substantially in memory, while many small meshes and materials can create expensive draw calls.

• Geometry: vertices, indices, morph targets and attributes.
• Textures: dimensions, channels, count and format.
• Scene: meshes, materials, lights and animation.
• Runtime: DPR, lighting, shadows, device and viewer.

Measure before changing the asset

Keep a reference export and profile a representative device and connection. Record transferred bytes, time to first useful render, interaction smoothness and approximate memory. Budgets depend on the phone, viewer, lighting, animation and visual target; universal limits are rarely honest.

Use the glTF Validator for structural issues and browser tools for network, CPU and memory. Change one factor at a time so improvements remain attributable.

Reduce geometry while protecting the silhouette

Remove subdivisions that do not affect the outline, hidden faces and details better represented by normal maps. Preserve joints and close-up features. Draco or Meshopt can reduce transfer size, but the GPU still receives geometry to render.

• Remove hidden objects, duplicates and unused attributes.
• Merge compatible objects when that genuinely reduces calls.
• Check normals, UVs and transforms before export.
• Review at the camera distance used in production.

Right-size textures and choose formats deliberately

Match texture dimensions to their maximum on-screen use. Packing occlusion, roughness and metallic channels can help when supported by the pipeline.

Use JPEG for opaque photographic detail, PNG when lossless edges or alpha matter, WebP for efficient web transfer where supported, and KTX2 when GPU texture compression fits the viewer and build pipeline. Compare visual quality and decode cost rather than choosing by extension alone.

Reduce materials, meshes and draw calls

Two equally sized files can render very differently. Reuse equivalent materials, remove near-identical variants and consider atlases where they simplify the scene. Do not merge everything blindly: maintainability, culling and visual requirements still matter.

Clean animation data

Delete unused clips, empty tracks, redundant keys and uninfluential bones. Reduce sampling only after visual comparison; mechanical movement, facial animation and cloth do not tolerate the same simplification.

Draco, Meshopt and client-side decoding

Geometry compression reduces bytes on the wire but does not fix oversized textures or excessive materials. It also requires a compatible decoder and CPU work on the client. Measure whether the smaller download actually produces a faster first render on lower-end hardware.

Prepare the export in Blender

Work on a copy, purge unused data, inspect UVs and materials, and apply transforms only when safe for the rig and pipeline. Export selected, necessary objects and clips. Reopen and validate the resulting GLB: the Blender viewport is not a web test.

Test memory, loading and interaction on mobile

Use at least one device near the lower end of the target range with production viewer settings. Watch first render, control responsiveness and repeated loads. Embedded image compression does not represent decoded GPU memory.

The linked DevXR model is a public viewer demonstration, not a compression benchmark or performance claim.

Common mistakes and final checklist

Avoid compressing without a baseline, shipping every texture at 4K, creating materials for tiny differences and testing only on a workstation.

• Validate silhouette and detail at the target distance.
• Remove unused objects, attributes, materials and clips.
• Justify texture dimensions and formats.
• Confirm compression support in the target viewer.
• Measure loading, memory and interaction on mobile.
• Review the exact viewer and iframe used in production.

Texture format decision table