GLB file size: what counts as too large for the web

Ask “how big is too big for a GLB?” and the answer depends entirely on where and how you are using it. A 50 MB file might be acceptable in a desktop configurator with a visible loading screen; the same file will reliably break AR on a customer's phone and fail the Shopify upload limit. The useful question is platform-specific: what is the ceiling for my use case?

Platform limits at a glance

These are the recommended file sizes and triangle targets for common 3D use cases on the web, based on platform documentation and real-world production experience:

The practical takeaway: if you are targeting mobile — and for e-commerce, you almost certainly are — optimise for the Shopify and mobile AR row, not the desktop row.

Why desktop tolerates large GLBs but mobile does not

A 50 MB GLB on a desktop browser with a fast ethernet connection and a discrete GPU is inconvenient but survivable — a few seconds of load time, maybe a brief stutter on first render. On mobile, the same file:

• Takes 30+ seconds to download on a typical 4G connection
• Requires more RAM than the browser tab budget on mid-range phones, causing a tab crash
• Exceeds the AR pipeline's internal memory ceiling, causing AR to silently fail

The practical rule: optimise for your lowest-powered expected device. For most Shopify merchants, that is a 2–3 year-old mid-range Android — the type of device that accounts for the majority of mobile commerce traffic globally.

What makes a GLB large

Almost all GLB bloat comes from three places:

Textures

Textures are almost always the biggest contributor. A single PNG texture at 4096×4096 pixels takes ~48 MB of GPU memory when expanded into VRAM — before mipmaps — and several megabytes on disk. Most product models include three to five texture maps: base colour, roughness/metalness, normal, emissive, and occlusion. At 4K resolution, that is 15–40 MB in the GLB file alone.

KTX2 with Basis Universal compression keeps textures compressed natively on the GPU, cutting texture data by 70–85% and VRAM usage by 4–6×. It is supported by all major web renderers and Shopify's viewer.

Analyze your texture footprint →

Uncompressed geometry

GLB files without Draco or Meshopt compression ship raw vertex data. A dense mesh with 500k triangles plus UV coordinates, normals, and tangents can be 30–40 MB in geometry data alone. Draco geometry compression, supported by Shopify's viewer, Three.js, Babylon.js and model-viewer, typically cuts this by 70–80% with no visible quality loss.

Reduce your file size →

Excess polygon density

Models exported from CAD software, photogrammetry, or high-detail sculpts routinely carry 500k to 5M+ triangles. Web viewers need 30–150k for most use cases; geometry beyond that costs file size and GPU time with no visible benefit at typical viewing distances. Selective decimation removes the excess while protecting silhouettes and material boundaries.

Check your polygon count →

Diagnose before you optimize

Before touching the model, run it through MeshGrade's free analyzer. It reports the exact file size, triangle count, every texture with its resolution and format, estimated GPU memory, and whether Draco and KTX2 compression are already in place — all benchmarked against the platform targets above. You will see immediately what is heavy and which fix will make the biggest difference, so you do not spend time on changes that won't move the needle.

A quick reference for common scenarios

• Shopify product model: target under 5 MB, under 100k triangles. Use KTX2 textures and Draco compression.
• WebGL product configurator (mobile): under 5 MB, under 150k triangles. Use KTX2 and Draco.
• WebGL scene (desktop-only): under 20 MB, under 500k triangles. Draco strongly recommended; KTX2 for any high-resolution textures.
• Meta Quest / WebXR experience: under 50 MB per asset, under 300k vertices total in scene. KTX2 critical for GPU memory.