Why File Size Matters for Web 3D
Every kilobyte of a 3D asset directly impacts load time, and load time directly impacts user engagement. Google’s research found that 53% of mobile visits are abandoned if a page takes longer than 3 seconds to load. A single unoptimized GLB file can easily exceed 50 MB, adding several seconds of download time even on fast connections and significantly more on mobile networks.
For e-commerce, the stakes are higher. Shopify reports a 94% average increase in conversions for merchants using 3D product models and recommends GLB files between 4–6 MB for optimal performance. 3D product viewers increase engagement and reduce return rates, but only when the experience loads fast. A 50 MB model that takes 8 seconds to appear on mobile will lose more customers than it converts.
Beyond user experience, Google’s Core Web Vitals directly factor into search rankings. Largest Contentful Paint (LCP) should be under 2.5 seconds, and Interaction to Next Paint (INP) should be under 200 milliseconds. Heavy 3D assets that block the main thread during parsing degrade both metrics, pushing your page down in search results.
How Draco Compression Works
Draco is an open-source compression library developed by Google for 3D meshes and point clouds. It encodes vertex positions, normals, texture coordinates, and other attributes into a compact binary format using the KHR_draco_mesh_compression glTF extension. The compressed data is reconstructed at decode time, producing geometry that is visually indistinguishable from the original, though quantization introduces minor precision differences at the data level.
For web delivery specifically, Draco compression is the single most impactful optimization. It typically reduces GLB file size by 60–90% on its own, with zero visual difference. A 10 MB GLB containing a detailed product model can become 1–2 MB after Draco compression alone. The decode cost is approximately 50–100 milliseconds on modern devices, which is negligible compared to the network time saved.
All major web 3D libraries support Draco natively: three.js (via DRACOLoader), Babylon.js, Google model-viewer, PlayCanvas, A-Frame, and React Three Fiber. The decoder is a small WebAssembly module loaded on demand, so there is no cost for pages that do not use 3D content.
KTX2 Textures: GPU Compression for the Web
Traditional image formats like JPEG and PNG must be fully decompressed into raw pixels before the GPU can use them. A single 4096×4096 texture requires 64 MB of VRAM in uncompressed RGBA format, regardless of how small the JPEG file was on disk. Load four textures for a PBR material (base color, normal, roughness-metallic, occlusion) and you are already using 256 MB of VRAM for one model.
KTX2, based on Khronos Group’s Basis Universal technology, solves this by keeping textures compressed in GPU memory. The same 4096×4096 texture uses roughly 16 MB of VRAM in ETC1S mode or 32 MB in the higher-quality UASTC mode. The texture is transcoded to the device’s native GPU format (BCn on desktop, ETC2/ASTC on mobile) at load time, so it works across all hardware.
For web delivery, KTX2 provides a double benefit: smaller file downloads and lower runtime VRAM usage. This is especially important on mobile devices, which typically have 2–4 GB of shared memory for both system and GPU use. Polyforge supports both ETC1S (maximum compression, good for diffuse textures) and UASTC (near-lossless, better for normal maps and detail textures) via the KTX2 texture compression option.
File Size Budgets for Web 3D
There is no universal file size limit for web 3D, but practical budgets depend on context. For product configurators and e-commerce viewers, aim for 4–6 MB per model (Shopify’s recommended target). For hero scene backgrounds and landing pages, 2–5 MB is a reasonable target. For scenes with multiple models (virtual showrooms, architectural visualization), individual assets should stay under 2 MB each. Above 20 MB is a danger zone for mobile, where texture memory is limited and shared with system RAM.
Polygon budgets follow similar logic. Mobile WebGL renderers perform best with 50K–100K triangles total on screen. Desktop WebGL2 and WebGPU can handle 500K–1M+ triangles comfortably, but draw call count matters more than raw polygon count for complex scenes with many objects.
A practical optimization workflow: start with Draco compression (the biggest file size win), then evaluate whether you need mesh decimation. If the model is still too large, apply texture compression (WebP for broad compatibility, KTX2 for best runtime performance). Finally, enable quantization and scene flattening for the last few percentage points of reduction.
Privacy-First Processing
All optimization happens entirely in your browser using WebAssembly. Your 3D files are never uploaded to a server. This is critical for teams working with unreleased product designs, proprietary assets, or client work under NDA. Files up to 100 MB are supported, with no server queue wait times and no data retention concerns.
Benefits of Web-Optimized 3D Assets
- Faster page loads : Smaller GLB files download faster, reducing time to first render and improving Core Web Vitals scores.
- Lower bandwidth costs : Draco and texture compression can reduce file sizes by 90%+, cutting CDN and hosting costs proportionally.
- Better mobile performance : KTX2 textures use 4× less VRAM than uncompressed equivalents, preventing GPU memory pressure on mobile devices.
- Higher engagement : 3D models that load instantly keep users interacting instead of waiting. Faster load times correlate with lower bounce rates.
- Improved SEO : Google Core Web Vitals factor directly into search rankings. Lighter 3D assets improve LCP and INP scores.
- Universal viewer compatibility : GLB with Draco compression is supported by three.js, Babylon.js, model-viewer, PlayCanvas, A-Frame, React Three Fiber, and all modern web 3D frameworks.