English
繁體中文
The first file a client sends is usually a surprise. Ours was a packaging line, exported as a single STEP assembly, 4 GB on disk. The request attached to it was entirely reasonable: put this on our website so buyers can walk around it. The browser version of that machine had to live in about two megabytes.
That is not an unusual ratio. It is close to typical. CAD software stores exact geometry for manufacturing, and the web needs approximate geometry for looking at. The distance between those two jobs is where GLB file size problems live, and almost all of them come from four sources that can be measured before anything is compressed.
Why exported files are always enormous
A STEP or SolidWorks assembly carries information a renderer has no use for. Export it straight to GLB and the bloat arrives in a predictable order.
| What is in the file | Typical share of size | Why it is there |
|---|---|---|
| Textures | 50–80% | 4K PNG maps, often five per material for a full PBR set |
| Geometry | 15–40% | Machined detail tessellated finely, interior parts fully modelled |
| Node hierarchy | 1–5% | Every sub-assembly, bolt and bracket kept as a separate node |
| Junk | 1–5% | Construction geometry, cameras, lights, unused materials, duplicate meshes |
One detail worth internalising: a single 4K texture in uncompressed PNG can be 30 MB on its own. A PBR material set — base colour, normal, roughness, metalness, ambient occlusion — is five of them. Before anyone touches the geometry, the texture side can already be larger than the entire budget.
Get the order of operations right
This is the mistake that costs the most time, and it is common enough to state plainly. The sequence is geometry, then textures, then compression, then splitting. Doing it backwards feels productive and changes almost nothing.
Compress a model that still holds two million triangles and it will still fail on a phone, because the decoder has to reconstruct all two million before the first frame draws. Shrink the textures but leave the interior of a machine fully modelled and you have saved bandwidth while keeping the GPU busy on surfaces nobody will ever see.
Measure first. Run gltf-transform inspect on the exported file and it prints a breakdown by mesh, texture and node count. That single report tells you which of the four buckets above is actually the problem, and it takes about ten seconds.
Where the 4 GB actually went
Concrete numbers are more useful than general advice, so here is the same packaging line, stage by stage.
| Stage | Size | What changed |
|---|---|---|
| STEP assembly as exported | 4.0 GB | — |
| After removing interior parts | 280 MB | Motors, frame, conveyor internals, cable runs deleted |
| After decimation | 84 MB | Flats to 40% of face count, machined faces held at 90% |
| After merging by material | 71 MB | About 2,400 nodes reduced to 38 draw calls |
| After texture conversion | 9 MB | Five 4K PNG maps per material to 2K KTX2 |
| After splitting and Meshopt | 1.9 MB first frame | Body loads first, attachments stream behind it |
Read that table as a ratio, not a recipe. Deleting hidden parts did about 93% of the work and required the least skill — it is just a decision about what a buyer can see. Texture conversion did another order of magnitude. Compression, the thing everyone reaches for first, accounted for the last portion. That ordering is typical. It is also the exact opposite of how most optimisation requests are phrased.
Getting to this point starts earlier than the optimiser anyway. Export settings decide whether half of it is fixable at all, and those are covered in preparing CAD files for a web 3D configurator.
Geometry: cut what nobody sees
Manufacturing models are built to be made, not to be looked at. Three passes remove most of the excess without touching what the buyer inspects.
Delete interior and hidden parts. In that packaging line, the frame, motors, conveyor internals and cable runs were fully modelled. None of them were visible once the outer panels were in place. Removing them took the file from 4 GB to under 300 MB before any decimation at all.
Decimate, but not everywhere. A flat panel with four holes survives at 40% of its original triangle count with no visible change. A machined face with chamfers, fillets or a bored hole does not — drop below about 85% there and the hole goes polygonal, which is exactly the thing a mechanical buyer zooms in on first. Decimate by material and by part type, not globally.
Merge what shares a material. Two hundred brackets with the same steel material become one draw call if they are merged into a single mesh. Draw calls matter more than raw triangle count on mobile, and a CAD hierarchy of 2,000 nodes produces 2,000 of them.
After those three passes, the packaging line sat at roughly 12 MB of geometry. Not yet acceptable, but no longer absurd, and the remaining weight had moved to where it could be handled cheaply.
Textures: the actual majority
Most teams spend their effort on polygons and their file size is dominated by images. Four rules, in order of impact.
Halve the resolution and you quarter the bytes. 4K to 2K is a 4× reduction in pixels, so roughly 4× in file size. On a product page the model occupies a third of a 1080p screen at most, which means 2K is already more resolution than the display can resolve at default zoom. Keep 4K only if your interface offers a genuine close-up view.
1K is enough for most web products. This sounds like vandalism to anyone who has spent weeks on material fidelity, and it is correct more often than not. A 1K base colour map on a machine housing is indistinguishable from 4K at the distances people actually browse.
Move to KTX2, not JPEG. Converting PNG to JPEG inside a GLB reduces bytes and increases decode time and VRAM use, because the GPU still needs the full uncompressed texture in memory. KTX2 with Basis compression stays compressed in GPU memory — typically 5 to 8 times smaller than PNG, and it decodes on the GPU rather than the CPU.
Drop maps you are not using. Ambient occlusion baked from CAD is usually wrong anyway. Metalness on a product that is entirely non-metal is a wasted 2K texture. Every map removed is weight and decode time returned.
On the packaging line, moving five 4K PNG maps per material to 2K KTX2 took the texture payload from over 200 MB to under 6 MB. That single step did more than all the decimation combined.
Draco or Meshopt
Both compress geometry, and the difference is a trade between ratio and decode cost.
| Draco | Meshopt | |
|---|---|---|
| Geometry reduction | Often 90%+ | Typically 70–80% |
| Decode cost on mobile | Noticeable — a WASM decoder runs before first paint | Low, decompression is fast |
| Good fit | Large static models, desktop-leaning audiences | Mobile-first pages, models that must appear fast |
| Watch out | Decode time can exceed the bandwidth saved on fast connections | Lower ratio, so it will not rescue a badly made model |
On a product page where the first frame must appear inside a second or two, Meshopt usually wins despite the worse ratio. Draco wins when the model is large, static and viewed on a workstation. There is also a hard constraint worth knowing: geometry that needs per-vertex work on the GPU, or partial streaming of vertex data, does not play well with Draco.
Split the model instead of squeezing it
At some point compression stops being enough and architecture takes over. A configurator is a good candidate for splitting because the parts are already logical units.
Load the body first at reduced detail, then stream the parts that belong to the selected configuration. A machine with four optional attachments only ever needs the one the buyer chose. A furniture configurator can ship a base frame plus one of twelve fronts rather than twelve full models. Colour variation belongs in a texture atlas or a material parameter, never in a duplicate model per colour.
The trade is complexity: more requests, more state to manage, and a progressive appearance that has to be designed rather than left to chance. On mobile it is usually worth it. On desktop, often not.
The budget I would work to
These are the numbers we hold ourselves to on delivery, and they are deliberately blunt.
| Item | Desktop | Mobile |
|---|---|---|
| First-frame model payload | ≤ 2 MB | ≤ 1 MB |
| Total scene after full load | ≤ 8 MB | ≤ 3 MB |
| Triangles in view | ≤ 500k | ≤ 150k |
| Texture resolution | 2K | 1K |
| Draw calls | ≤ 150 | ≤ 80 |
| LCP on the page | < 2.5 s | < 2.5 s |
That last row is the one that actually matters and the one most 3D projects ignore. A beautiful model that pushes Largest Contentful Paint past four seconds is a net loss, because the page fails Core Web Vitals and search performance follows. The model is not exempt from the page budget — it is usually the largest item in it.
When this advice is wrong
There is a version of the above that goes badly. If the configurator is the product — a flagship watch, fine jewellery, a car in a showroom — fidelity is the feature, and a 1K texture is the wrong call. Nobody buys a ring because it loads in a second.
Those projects belong to a different architecture. Cloud streaming renders on a server and sends video, so any device gets photoreal quality and the client does almost no work; the cost is per session and scales with traffic. It is the right answer for a small number of products and the wrong one for a catalog of forty machines. The question to ask is whether the buyer is evaluating a purchase or admiring an object, and it is usually obvious within one conversation.
What the work actually costs
Optimising one hero model properly is one to three days of artist time. That sounds excessive for "make the file smaller" until it is compared with the alternative: a product page failing Core Web Vitals for a year, with the organic traffic loss that quietly follows.
Multiply by the number of hero models and it becomes a real line in the project budget. Which is why it should be scoped before anyone quotes a number, rather than absorbed afterwards as an overrun. Teams that skip this step do not save the days. They spend them later, on a fire, at the worst possible time.
What the finished result looks like in practice varies a lot by product type. Our case studies show the range, from sanitary ware that has to hold up under close inspection to industrial instruments where the point is assembly sequence rather than surface finish.
How to verify before it ships
Four checks, all of which take minutes and catch nearly everything.
Run gltf-transform inspect on the final file and confirm the texture and geometry split is what you intended. Load the page on a throttled mobile profile in Chrome DevTools with cache disabled, and watch when the first frame actually appears rather than when the network finishes. Check draw calls and triangle count in the renderer's own stats panel, since these decide mobile performance far more than file size does. And run PageSpeed Insights on the live URL, because that is the number Google will judge you on.
Once the model is light enough to load, the interaction layer is a separate discipline — mobile 3D product interaction covers what changes when the viewer is a thumb rather than a mouse.
The 4 GB packaging line finished at 1.9 MB for the first frame, with the rest of the machine streaming in behind it. Nobody who has looked at it on a phone has asked how many polygons it has. Send us a file and we will tell you what your model can realistically come down to, and what it will cost in fidelity.
FAQ
Q: What is a reasonable GLB file size for a website?
For a first frame on a product page, under 2 MB on desktop and under 1 MB on mobile. Total scene weight after everything loads should stay under 8 MB and 3 MB respectively. A file much above that will usually still load, but it will cost you Largest Contentful Paint, and that is a search performance problem as well as a user experience one.
Q: Is Draco compression always the best choice?
No. Draco reduces geometry by up to 90% but needs a WASM decoder before the first frame draws, which on a mid-range phone can cost several hundred milliseconds. Meshopt compresses less and decodes nearly instantly, which is usually the better trade on mobile-first product pages. Choose by where the model is viewed, not by which ratio looks better in a report.
Q: Can I just use a GLB file size reducer tool?
It will help, and it will not be enough on its own. Automatic reducers typically apply Draco and texture resizing uniformly. The gains that matter usually come from removing interior geometry and unused maps first, and from not decimating machined surfaces that buyers inspect closely — decisions that require knowing what the product is.
Q: Why is my GLB so much bigger than my OBJ or FBX?
It probably is not, in geometry terms. GLB embeds textures inside the single file, while OBJ and FBX often reference them externally, so the comparison hides most of the weight. Compare the exported folder size rather than the single model file, and check the texture table in an inspection report before drawing conclusions.
Q: Does compressing the model hurt visual quality?
Geometry compression generally does not, because it is lossless in practice for viewing purposes. Texture compression does, and it is the part to be deliberate about. Halving resolution is usually invisible at browsing distance; dropping normal maps, or compressing them too aggressively, is where surfaces start to look flat.
