How big should a GLB file be for a website?

Most answers to this stop at "it depends" without saying what it depends on. Here are four models running live in a browser, measured, and the thing that actually predicts their size.

The four models

These four models were measured from the deployed site on 4 August 2026. The table preserves that dated snapshot; it is not a fresh benchmark of today's loading speed. Counts came from the files' glTF accessors and image arrays.

Read those numbers again

The relationship is the opposite of what most people expect:

• The DNA strand has 3.7× the rover's triangles but is only 1.5× the file size.
• The turbofan has half the DNA's triangles but is 2.7× the file size.

In this sample, triangle count alone does not predict the download. The engine has fewer triangles than the DNA strand but more texture images and a larger file.

Inspect texture bytes as well as geometry. Image dimensions, format and content affect their size; texture count alone is not a universal predictor. These four examples show why reducing triangles first can miss a substantial part of the download.

So what should you budget?

These are working numbers, not standards. They are where we set the line for our own work, and the reasoning is stated so you can move it for your case.

Triangle count affects geometry size and rendering workload. Materials, draw calls, texture memory, decoding and device capability also matter. A file-size target cannot guarantee a frame rate or a particular loading time.

The loading plan changes the budget

A catalog with 500 products should not download 500 models when it opens. Show the catalog first and load the selected product's 3D view when needed. If many products share a base and accessories, reuse those assets and fetch only missing parts when options change.

That can reduce duplicate downloads and maintenance, but it is not automatically faster than loading one optimized GLB. More requests, assembly work and separate materials can add costs. Compare first load, option switching and memory use under the same conditions.

Read the architecture guide: Does a 500-product catalog need 500 separate 3D models?

Morph targets need their own checks

A character with facial blend shapes has a different data budget from a static prop. Check the base mesh, textures, animation and morph data separately rather than applying a prop's file-size target to the whole character.

• Draco's glTF extension does not compress morph-target data. Compressing the base mesh can still help, but it may leave much of a character's data untouched.
• Meshopt can compress morph targets and animation. The glTF Transform documentation explicitly supports those data types. Exporter, optimization settings and runtime compatibility still need testing; a failure in one pipeline does not establish that the format universally breaks Character Creator models.
• Check the animated result. Compare facial poses, shading and motion with the source before accepting a smaller export. Dropping morph normals can change the result and is not a universal safe setting.

Our Character Creator size breakdown records earlier pipeline observations. Its compression observations should be read as specific to those tested exports, not a blanket limitation of Meshopt or quantization.

What to do, in order

1. Measure before you optimize. Look at the split between geometry and textures first. Most people start by decimating a mesh that was never the problem.
2. Delete textures that are not textures. A metallic or roughness map that is one flat value is a scalar factor wearing a costume. On one job that removed ten image files with no visual change at all.
3. Choose textures for the target viewer. Compare resolution and visual quality, then choose supported formats. WebP can reduce transfer size; KTX2/Basis can also reduce GPU texture memory on supported hardware. They address different parts of the workload.
4. Test geometry compression. Compare Draco or Meshopt with the required loader support, decoding cost and animation behavior. Preserve a working source export.
5. Re-measure. Optimization without a before and after number is guessing.

How these were measured

Worth stating, because "3D file size" numbers on the web are usually quoted from memory or from a modelling package, and both mislead.

Byte sizes are what the server actually sends, taken from the HTTP response, not what the file looks like on a local disk before compression. Triangle counts were read directly out of each GLB's JSON chunk by summing the index accessor counts across every mesh primitive and dividing by three.

Textures were counted from the glTF images array, so they are the images actually packed into the file rather than what exists in the source project.