A 3D product model file size of 5 MB is already too heavy for a product page that a buyer opens on a phone. The weight that survives a mid-range Android device on an ordinary mobile connection is closer to 2 MB — and the reason is arithmetic, not taste. At 5 Mbps, every megabyte costs 1.6 seconds before the viewer can render a single frame.
That number changes the conversation. Most suppliers treat the model as a marketing asset and the file size as the 3D studio's problem. Buyers treat it as the first thing that loads on a page they did not choose to wait for. This is the budget table, the four places the bytes actually go, and the six checks to run before you paste a 3D view link into a quotation email.
The 3D product model file size table: what a phone downloads first
Download time is file size × 8 ÷ connection speed. Nothing else is in that equation — no rendering, no zooming, no first frame. The table below assumes a steady connection and ignores TLS setup and round-trip latency, so real phones are slower than the numbers shown.
| Model file size |
10 Mbps |
5 Mbps |
1.6 Mbps |
What the buyer does while waiting |
| 2 MB |
1.6 s |
3.2 s |
10 s |
Turns the model, maybe reads a spec line |
| 5 MB |
4 s |
8 s |
25 s |
Scrolls past, or taps the still image instead |
| 10 MB |
8 s |
16 s |
50 s |
Assumes the page is broken |
| 20 MB |
16 s |
32 s |
100 s |
Closes the tab |
| 50 MB |
40 s |
80 s |
250 s |
Never reaches the model at all |
Read the 50 MB row twice. That is a 13-second download on a good office connection and more than four minutes on the weak mobile link a buyer might be using in a warehouse, a showroom or a hotel. A model that large is not a presentation asset; it is a file transfer the buyer did not agree to.
A 3D product model is the only product asset where the buyer downloads the entire product before seeing any part of it. A photo can arrive progressively, top rows first. A video can start after a few seconds of buffer. A GLB cannot.
Why the whole model has to arrive first
The glTF 2.0 specification is explicit that the format is not a streaming format: the binary data is streamable in principle, but glTF defines no streaming constructs. A viewer therefore loads the asset, parses it, then renders. There is no partial 3D preview that looks like the product.
The container matters here. A GLB file bundles the JSON scene description and the binary buffers into one file with no base64 overhead, which is efficient for a single request but means the buyer waits for the whole package. A split .gltf plus .bin plus separate textures allows the viewer to fetch pieces independently and can start earlier — at the cost of more requests and more things to get wrong. For a single-SKU product card, one GLB is usually the right trade. For a 60-SKU range, split files shared across variants can be smaller in total.
None of this shows up as an image in performance reports, which is why it goes unnoticed. The Largest Contentful Paint element on a product page is normally the hero image or a text block, not a WebGL canvas. Google's guidance still puts a good LCP at 2.5 seconds or less at the 75th percentile. If your viewer's JavaScript and model download compete with that hero image for bandwidth, the page misses the threshold while the 3D team reports that "the model renders fine."
What the rest of the page already weighs
The 2024 HTTP Archive data in the Web Almanac puts the median desktop page at 2,312 KB and the median mobile page at 2,037 KB. On mobile, images alone account for about 900 KB of that median page.
Put the model next to those numbers:
| Asset |
Typical weight |
Compared with the median mobile page (2,037 KB) |
| Median mobile page, everything included |
~2 MB |
1× |
| A 2 MB GLB |
2 MB |
Doubles the page |
| A 5 MB GLB |
5 MB |
2.5× the whole page |
| A 20 MB GLB |
20 MB |
10× the whole page |
That is the honest way to set a budget. A 3D view is one element on a page that also carries your gallery, the spec table, reviews, tracking scripts and the theme. If the model alone is bigger than the median page, the model is the page — and the buyer is paying for it in seconds.
Weather and venue WiFi make this worse, and so does the device. A mid-range phone from three years ago decodes a 4096-pixel texture more slowly than the laptop the file was approved on. Test on the phone, not the studio monitor.
Where the bytes go, and which compression fixes which part
A 3D product model file size is spent in three buckets, in this order of usual dominance: textures, geometry, and everything else (animation, cameras, extra nodes). Suppliers are often surprised that geometry is not the main cost. A photo-derived model with a single 4096 × 4096 PNG texture can weigh more than the mesh it wraps.
| Bucket |
What inflates it |
What actually reduces it |
| Textures |
4096 px PNG maps, unused normal and roughness maps, embedded colour profiles |
Smaller maps at the size the viewer displays, JPEG or KTX2, dropping maps the material does not use |
| Geometry |
Scanned or subdivided meshes with millions of triangles, duplicated parts |
Decimation to the visible detail level, instancing repeated parts, Draco geometry compression |
| Everything else |
Animation clips nobody plays, hidden nodes, cameras, lights |
Deleting what the viewer does not need; a product turntable needs one camera |
Two ratified Khronos extensions do most of the compression work, and they solve different problems. KHR_draco_mesh_compression streams compressed geometry instead of raw vertex data. KHR_texture_basisu stores textures as KTX2 with Basis Universal supercompression, which cuts transmission size and GPU memory footprint.
Both are extensions, not baseline glTF. The viewer must support them, and the file must declare them in extensionsRequired when the uncompressed fallback is absent. Before you send anything, open the exported file in the exact viewer the buyer will use — your product card, your website, a marketplace's 3D slot. A file that loads in Blender proves nothing about a phone browser.
Six checks before you send a 3D product view link
Run these in order. The first two catch most of the damage; the last four catch the failures that produce support emails instead of orders.
Check 1: it is a web export, not a working file
A .blend or .step file is an authoring document. It carries history, cameras, materials and sometimes linked textures that live in a folder on someone's laptop. The web container is GLB, and the scene should contain one product, one camera, and materials the viewer can read. If the export dialog asks about "apply modifiers" or "include hidden objects," the answer is yes to the first and no to the second.
The source images behind the model matter as much as the export. A model built from mixed angles and inconsistent lighting will show those seams when the buyer rotates it — the same reason a mismatched photo set fails on a product page. If the photo set is still being assembled, start with photos for a 3D product view before touching the exporter.
Check 2: the weight matches the connection, not the studio
Open the export and read the 3D product model file size in megabytes, then compare it with the table above. Do this on the exported file, not the source project — a 40 MB working file can export to 3 MB, and a 3 MB working file can export to 30 MB once textures are packed.
If it is over budget, fix the biggest bucket first. Replacing four 4096-pixel PNG maps with one 1024-pixel JPEG map usually removes more weight than any geometry change. Draco and KTX2 come after that, because they make a reasonable asset smaller rather than making an unreasonable asset acceptable.
Check 3: the first frame is a poster image, not a blank canvas
Lazy-load the viewer and show a still image — ideally the same angle the model opens at — until the buyer interacts. This keeps the 3D canvas out of the critical path and gives the page a real LCP candidate.
Interaction responsiveness is the metric most 3D pages fail next. Google's Interaction to Next Paint threshold is 200 milliseconds at the 75th percentile; above 500 ms is poor. A heavy model plus a physics engine plus a shadow pass can push a tap-to-rotate past that on a mid-range phone even when the page loads quickly.
Check 4: rotation works with one thumb
Hold the phone in one hand and rotate the model with the thumb. If the gesture needs two fingers, if the model drifts after release, or if zooming moves the rotation centre, the buyer will fight the viewer instead of reading the product.
Test the edges too: the top, the underside, the back panel. A viewer that clamps rotation at 45 degrees hides exactly the surfaces a buyer wants to inspect — the ones the studio never photographs.
Check 5: the shape still matches the product
Rotate the model against the real unit and the measured drawing. Watch the silhouette, the hardware, the seam lines and the thickness of any panel edge. Then watch the parts the buyer will check: hinges, feet, handles, the profile of a moulding.
Conversion of a photo into a 3D asset is a presentation step, not a measuring step. The model may smooth a curve or straighten a slight bow; it must not invent a handle, remove a seam, or change a proportion that the drawing states. If the model and the drawing disagree, the drawing wins and the model gets rebuilt.
This is also where the two output types have to stay honest with each other. A rotatable model shows shape and how parts meet; the measured diagram shows the numbers. Software that pins measured dimensions onto the photo and builds the rotatable model from the same source keeps those two views from drifting apart — and it keeps the dimension on the annotation, where a buyer can read it, instead of inside the render, where nobody can measure it.
Check 6: there is a fallback for the buyer who cannot see it
Corporate laptops block WebGL. Some browsers disable it by default. Older phones run out of memory on large textures. In every one of those cases the buyer should still get a still image, the spec table and the contact button.
Write the fallback into the page, not into the plan. A viewer that shows a grey box with a spinner when WebGL is unavailable is worse than no viewer at all, because the buyer now believes your product page is broken.
What a 3D view can and cannot prove
A 3D product view is a presentation asset: it communicates shape, proportion and how parts relate. It is not a measurement record. The model's apparent size on screen depends on the camera, the field of view and the buyer's screen, so no buyer can read a dimension off it, and no supplier should imply they can.
That distinction is worth stating on the page itself. One line — "dimensions are measured on the product, the 3D view shows shape" — prevents the most expensive misunderstanding in this workflow: a buyer who believes the model is a dimensioned drawing and orders against it.
| Buyer question |
What answers it |
What does not |
| "Is it exactly 1,200 mm wide?" |
A measured spec diagram with the dimension on the photo |
A 3D render, however detailed |
| "What does the back look like?" |
3D view, or a rear photo set |
A front-only gallery |
| "Will it fit through my door?" |
Door width plus the smallest packed dimension |
A model that can be scaled on screen |
| "How does the base attach?" |
Breakdown diagram, or a 3D view with the base separated |
A single beauty render |
When a 3D view is not worth the weight
3D is not the default answer to every buyer question, and a product page that carries every format is slower than one that carries the right one. Use this decision rule.
| The buyer's real question |
Cheaper asset that answers it |
Use 3D when |
| "What does it look like from the side?" |
360 photo sequence or a four-angle set |
The buyer needs to rotate freely, not step through frames |
| "How big is it?" |
Measured diagram with dimensions on the photo |
Never — 3D does not answer this |
| "How does it come apart?" |
Breakdown diagram with callouts |
The assembly sequence itself is the selling point |
| "Is the finish right?" |
Macro photos under consistent light |
Never — texture maps are not colour proofs |
If the question is "which format do I send", the decision usually lands between a 3D view and a photo sequence rather than between 3D and nothing. The trade-off is file weight, interaction and how much control the buyer needs; 3D product viewer vs 360 photos covers that split in detail.
When 3D does earn its place, put it where it can be seen: a 3D product view that opens next to the measured specs, in the same card the buyer forwards internally, beats a viewer buried three clicks into a catalogue page.
FAQ
How big should a 3D product model be for a website?
Under 5 MB, and under 2 MB if buyers are likely to open the page on a phone. The ceiling comes from arithmetic, not preference: at 5 Mbps a 5 MB model needs 8 seconds before the first frame, and that is before the viewer's JavaScript runs. Check the actual exported GLB, not the source project.
Do 3D models slow down a product page?
Yes, and usually in two places. The download competes with the hero image for bandwidth, which pushes Largest Contentful Paint past Google's 2.5-second good threshold. The viewer's JavaScript then competes for the main thread, which pushes interaction latency toward the 200 ms INP threshold. Measure both in PageSpeed Insights with the model in place, not with a placeholder.
What is the difference between GLB and glTF?
GLB is the binary container; glTF is the format. A .gltf file is JSON that points to separate .bin and image files. A .glb packs the JSON and the binary buffer into one file without base64 encoding, so it is one request and slightly smaller than the equivalent embedded JSON. Both are glTF 2.0 and both load in a compliant viewer.
Can I reduce a 3D model file size without losing the shape?
Yes, in three moves: remove textures and maps the material does not use, decimate geometry to the detail the viewer can actually display, then apply Draco to geometry and KTX2/Basis to textures. Re-check the silhouette and the part count after each step. The cheap win is almost always textures; the expensive mistake is decimating a curved surface until the profile no longer matches the drawing.
Can a buyer measure a product from a 3D view?
No. A 3D view shows shape and proportion; it cannot certify a dimension, because apparent size depends on camera, field of view and screen. Buyers who need a number should read a measured spec diagram or a dimensioned drawing, where the dimension is attached to the product rather than inferred from a render.
Sources & References
