GLB Compressor

A GLB file usually contains three weight classes: geometry buffers, material JSON and embedded textures. On low poly assets, geometry is often not the largest part; a 600-triangle object with a 2048px PNG can be heavier than a 20k-triangle mesh with a 1024px compressed texture. Start by checking what dominates the file before choosing a compressor, because geometry compression will not fix a texture-heavy GLB.

Draco and meshopt solve the geometry part differently. Draco generally produces very small geometry streams, but decoding can be CPU-heavy and needs the loader to ship a Draco decoder. Meshopt compression is designed for fast GPU-friendly decode and pairs well with vertex-cache optimization; it is often the practical default for interactive web scenes. For a product viewer or configurator, shaving 200 KB is not useful if it adds a visible decode stall on mid-range phones.

Quantization reduces the precision of vertex attributes before or during compression. Positions, normals, tangents and UVs rarely need full 32-bit floats for a small low poly prop, but overdoing it can make straight edges shimmer, UV seams crawl or baked normals look dented. Test quantized output in the engine, not only in a file-size report, because the wrong normal precision can look fine in a neutral viewer and bad under your actual lights.

Texture compression is often the real win. Resize texture atlases to the actual viewing need, convert color maps to WebP for broad web use or KTX2/Basis when your GLB loader supports GPU-native transcoding, and avoid embedding unused metallic, roughness or normal maps for intentionally flat-shaded models. A good GLB compressor pipeline records both file size and first-frame time so the final choice is based on user experience, not just an impressive percentage reduction.