Rig Bake › Guides › When a GLB is too heavy for the web

When a GLB is too heavy for the web

Slow first paint, a spinning loader, a tab that dies on an older phone — three different causes with three different fixes. Here is how to tell them apart.

Open Rig Bake — free, in your browser

No sign-up. No upload — models stay on your machine. Works in any WebGL 2 browser.

A model that behaved perfectly in Blender can be unusable the moment it is served over the network to a phone. The confusing part is that the obvious culprit — the triangle count — is usually not the one causing the symptom you are seeing.

There are three separate budgets, and they fail in three distinguishable ways. Work out which one you have blown before you start cutting anything, because the fix for one does almost nothing for the others.

How to do it

Name the symptom precisely. Long wait before anything appears at all: a download-size problem. Appears, then the page stutters or the frame rate is poor: a render-cost problem. Tab reloads itself or the model never appears on mobile: a memory problem. These are not the same fault.
Look at where the bytes actually are. Drop the file into model doctor or open it in any glTF inspector and compare the texture payload against the geometry. In a typical GLB the images are 80–95% of the file. If that is true of yours, the triangle count was never your download problem.
For download size, compress the textures. Run it through Compress GLB. Capping textures at 1,024 px and re-encoding typically removes 60–80% of the file. A 4K albedo map on an object that occupies 200 screen pixels is pure transfer cost with no visible return.
For frame rate, cut triangles and draw calls. Now the triangle count matters. Reduce polygons to what the object needs at the size it is actually displayed. Separately, check how many meshes and materials the file contains — thirty small meshes with thirty materials cost far more per frame than one merged mesh, independent of triangles.
For memory, attack texture resolution first. GPU texture memory is the usual reason a model kills a mobile tab, and it is driven by pixel dimensions rather than by file size — a well-compressed 4K JPEG still expands to roughly 67 MB once uploaded to the GPU. Halving a texture's dimensions quarters what it occupies. This is why compression alone can fix a crash that decimation could not touch.

Why the file size barely moves when you halve the triangles

This is the single most common surprise, and it follows directly from what a GLB contains. Geometry is stored as tightly packed binary — a position is twelve bytes, a normal twelve, a UV eight. A 50,000-triangle mesh might occupy two or three megabytes. The four texture maps on that same mesh can easily occupy thirty.

So halving the triangle count on a 40 MB model might hand you back a 38 MB model. Nothing is broken; the mesh was simply never where the weight was. Decimation buys you frame rate. Texture compression buys you download size. Reaching for the wrong one is why a lot of optimization sessions end with no measurable improvement.

The number that actually predicts a mobile crash

Uncompressed GPU texture memory is the figure worth computing, and it ignores your file size entirely. Roughly, width × height × 4 bytes per texture, plus about a third again if mipmaps are generated — which they usually are. A single 4096 × 4096 map is about 67 MB before mipmaps. Four of those on one model is a quarter of a gigabyte of GPU memory for one object.

Older phones will fail well below that, and the failure mode is not a friendly error — the tab reloads, or the model silently never appears. If you are debugging a model that works everywhere except on someone's phone, this is almost always the reason.

A reasonable target for a model on a public page

For a single hero object on a marketing page or a product viewer, aiming for under 5 MB total is a sane goal, with textures at 1,024 px or 2,048 px for something inspected closely. Under 2 MB feels instant on a mobile connection. Above 15 MB you should assume a meaningful share of visitors leave before it finishes.

Triangle counts for the same job are less demanding than people expect: a product that the user orbits is convincing at 20,000–50,000 triangles, and a decorative object in a page section rarely needs more than a few thousand. If your file is above these on both axes, fix the textures first — it is the larger win for less visual cost.

Frequently asked questions

Why is my GLB so large when the model is simple?

Almost certainly the textures. A simple shape with a 4K texture set is a large file; a complex shape with a 512 px texture is a small one. Open the file in an inspector and compare the image payload against the buffer holding the geometry — the ratio usually answers the question immediately.

Does reducing the polygon count make the GLB download faster?

A little, and usually much less than you hope. Geometry is a small fraction of a typical GLB. If download speed is the problem, compress the textures — that is where the bytes are.

My 3D model crashes Safari on iPhone. What do I fix?

Texture resolution, before anything else. GPU texture memory is driven by pixel dimensions rather than compressed file size, so a small JPEG can still expand to tens of megabytes on the GPU. Cap the maps at 1,024 or 2,048 px and retest — this resolves the majority of mobile failures.

Should I use Draco compression?

Draco compresses geometry, so it helps in proportion to how much of your file is geometry — which, as above, is often not much. It also costs decode time on the client. Compress the textures first, measure, and add Draco afterwards if geometry is genuinely a significant share of what remains.

How small should a 3D model be for a website?

Under 5 MB is a reasonable target for a hero object and under 2 MB feels instant on mobile. Beyond roughly 15 MB you should expect to lose visitors during the load, regardless of how good the model looks once it arrives.