glTF Optimizer

Optimization starts with the scene graph, not the byte counter. Generated or exported GLB files often contain empty nodes, leftover cameras, unused materials, duplicate accessors and mesh primitives split only because they once had separate material slots. Removing unused data and merging compatible primitives can cut draw calls before any compression is applied, which is why two files with the same byte size can perform very differently in a browser scene.

Geometry optimization usually combines vertex cache reorder, overdraw reduction, attribute quantization and optional compression. glTF Transform and meshoptimizer can reorder indices so nearby triangles reuse vertices more efficiently on the GPU, then quantize positions, normals and UVs to fewer bits when the precision loss is invisible. Draco can produce smaller downloads, but it is CPU-heavy to decode; EXT_meshopt_compression is often the better real-time choice for web viewers because it balances size and decode speed.

Textures are usually the largest payload even for low poly models. A 5k-triangle prop with a 4096px PNG texture is not optimized, even if the mesh is tiny. Resize props to 512 or 1024px, reserve 2048px for close hero assets, convert color maps to WebP or KTX2/Basis where your loader supports it, and avoid alpha unless the material truly needs transparency. Texture decisions often save more bandwidth than geometry compression on flat-shaded assets.

A finished optimization pass should be measured in three ways: final bytes, draw calls and visual difference at the real viewing distance. Load the GLB in a browser viewer, compare triangle count with the source, inspect material count, and check for UV seams or normal artifacts after quantization. For production, keep the editable source separate from the optimized delivery GLB so future changes are made on clean source data instead of repeatedly compressing an already-lossy file.