The Problem, Stated Plainly
A 3D artist delivers a beautiful model. A developer embeds it. The page now weighs 34MB, takes eleven seconds to become usable on a phone, and the client asks why the site got slower after the upgrade.
This happens because the file that looks correct in modelling software and the file that belongs on a website are entirely different artefacts. The production model has millions of polygons and 4K textures because it was built for rendering, where file size is irrelevant. The web version needs to be a hundredth of the size and look identical at the sizes it will actually be viewed at.
Getting from one to the other is a defined pipeline, not a matter of exporting more carefully.
First: Do You Actually Need Interactive 3D?
The cheapest optimisation is not shipping the model at all. Three options exist and only one of them involves WebGL.
| Approach | Weight | Best for |
|---|---|---|
| Static rendered images | 100–400KB | Most product pages; nothing beats it for performance |
| Pre-rendered turntable (video or image sequence) | 500KB – 3MB | Showing all angles without interaction; works on every device |
| Interactive 3D viewer | 1.5MB – 8MB | Configurators, variant selection, products needing free inspection |
A large share of the 3D viewers we are asked to fix should have been turntables. If the only interaction is rotation, a 36-frame image sequence delivers the same experience at a fraction of the cost and works on every device without a fallback path.
Choose the interactive viewer when the customer genuinely benefits from control — configuring a variant, inspecting a joint, judging scale from a specific angle.
The Optimisation Pipeline
1. Reduce geometry
A production model may carry two million polygons. A web viewer displaying the product at 800 pixels needs a small fraction of that. Decimate aggressively and check the silhouette at the actual display size — that is the only place polygon reduction becomes visible.
Where fine detail matters — engraving, texture, small surface relief — bake it into a normal map rather than keeping it as geometry. A normal map at 1K costs a few hundred kilobytes and preserves the visual result of a hundred thousand polygons.
2. Fix the textures, which are usually the real problem
Textures typically account for seventy to ninety percent of a web 3D payload, and they are where most of the easy savings sit.
- Drop texture resolution to what the display size justifies. 4K maps for a product shown at 600 pixels are pure waste; 1K is usually generous, 2K is the ceiling.
- Combine separate maps into packed channels rather than shipping several files.
- Use GPU-friendly compressed texture formats such as KTX2 with Basis, which stay compressed in GPU memory rather than decompressing to full size like a PNG or JPEG.
- Atlas multiple materials into a single texture where the model allows, reducing both file count and draw calls.
3. Compress the mesh
Export as glTF/GLB — the format designed for web delivery — then apply Draco or Meshopt compression. Geometry commonly drops by eighty to ninety percent with no visible difference. Meshopt decodes faster; Draco compresses slightly harder. Either is a substantial improvement over an uncompressed export.
4. Simplify the scene
- Reduce the number of distinct materials — each one is a draw call.
- Use a compressed environment map for lighting rather than multiple dynamic light sources.
- Bake static shadows into textures rather than computing them in real time.
- Remove hidden interior geometry the camera can never reach.
- Delete unused animation tracks, cameras, and empty nodes that survive export.
5. Target the numbers
| Asset | Target | Hard ceiling |
|---|---|---|
| Product viewer GLB | Under 1.5MB | 3MB |
| Complex configurable scene | Under 4MB | 8MB |
| Triangle count (mobile) | 50k – 150k | 300k |
| Texture resolution | 1024px | 2048px |
| Draw calls | Under 30 | 60 |
Loading It Without Damaging Core Web Vitals
Even a well-optimised model will hurt your metrics if loaded carelessly.
- Never let the 3D canvas be your LCP element. Show a static rendered image immediately, and swap to the interactive viewer once it is ready. Your LCP measures the image, which loads in milliseconds.
- Lazy-load on intersection. Do not download the model until the viewer scrolls into view, or until the visitor clicks a "view in 3D" control. Many visitors never scroll that far.
- Code-split the 3D library. A WebGL renderer is a large JavaScript dependency and should not be in your main bundle. Load it dynamically alongside the model.
- Reserve the space. Give the container fixed dimensions so the swap from placeholder to canvas causes no layout shift.
- Show progress. A visible loading state prevents the page feeling broken during a two-second download.
- Dispose properly. Release geometry, textures, and the renderer when the component unmounts, or single-page navigation will leak GPU memory until the tab crashes.
- Throttle when not visible. Pause the render loop when the canvas is off-screen or the tab is backgrounded — a continuously running loop drains battery and makes the whole page feel sluggish.
These interact directly with the metrics discussed in our guides on Interaction to Next Paint and diagnosing slow websites.
Device Reality
WebGL is supported almost everywhere; adequate GPU memory is not. A mid-range Android phone from three years ago has a small fraction of the graphics capability of a current flagship, and a scene that runs smoothly on a MacBook may crash the tab on it.
- Test on a genuinely mid-range Android device, not only on your own phone.
- Serve a lighter model variant to mobile — lower polygon count, smaller textures.
- Cap the device pixel ratio at 2 rather than rendering at native resolution on high-density screens, which quadruples fragment work for no perceptible gain.
- Detect WebGL support and fall back to a static image or turntable rather than showing an error.
- Watch memory rather than only frame rate. Crashes on mobile are usually memory exhaustion, not slow rendering.
Accessibility and Indexability
Content inside a canvas is invisible to search engines and to screen readers. Everything the 3D communicates must also exist as text.
- Keep full product descriptions, dimensions, materials, and variant names as HTML outside the canvas.
- Provide static images with descriptive alt text as the non-interactive equivalent.
- Ensure the viewer is keyboard-operable, or clearly marked as decorative and skippable.
- Respect reduced-motion preferences by disabling auto-rotation for visitors who have asked for less movement — part of the broader approach in our accessibility guide.
When It Is Worth It
Interactive 3D justifies its complexity for products where photographs leave genuine uncertainty — furniture where scale and proportion matter, jewellery where the setting needs inspection, footwear, hardware with mechanisms, and anything configurable. In those categories it measurably reduces hesitation and return rates.
For a product that photographs clearly from four angles, a viewer is engineering effort spent on novelty. The honest question is whether a customer has a question that rotation answers. If not, ship excellent renders instead — which is a decision our 3D versus photography comparison works through.
Kalex Studio builds interactive 3D as part of custom web platforms, with the optimisation pipeline and fallbacks handled as part of the build rather than bolted on afterwards. To discuss adding 3D to your product pages without losing your performance scores, get in touch.