From Blender to Browser in Under 3MB

Competing Budgets

Web 3D assets must satisfy four budgets simultaneously. Violating any one of them degrades the experience.

These budgets interact. Draco compression cuts download size but adds parse time. Sharper textures look better but eat GPU memory. More polygons mean a cleaner silhouette but less rendering headroom.

So the pipeline is a series of informed trade-offs, not a single setting you can max out.

The Naive Approach

The export-and-ship workflow that creates most performance problems.

Those two are about what goes into the file. The next two are about how it travels and how big it is on the wire.

Each of these is easy to miss in development, where the file is local and the GPU is generous. They compound, and the last one is how they surface.

glTF as the Standard

glTF (GL Transmission Format) is the standard for web 3D. Three.js loads it natively, it is designed for efficient transmission, and it is extensible via the Khronos extensions system. There are two flavours of the file, and the choice matters.

Ship the GLB file (.glb), the binary glTF format, for production: a single file with geometry, textures, and metadata packed together and no base64 overhead. Keep the .gltf JSON variant for debugging, where being human-readable helps. A plain glTF file with embedded textures is bigger and slower to parse, so it should never reach a real user.

The Pipeline

The complete path from authoring to browser delivery.

Blender Export Settings

The Blender glTF exporter has a handful of settings that decide your starting file quality and size. Get them right and the optimisation step does less work.

gltf-transform CLI

gltf-transform is the tool that does the real work of web 3D optimisation. It operates on glTF files with a composable set of commands, so you can run the full pipeline in one go or step through it for control.

# Install
npm install -g @gltf-transform/cli

# Full optimisation pipeline (one command)
gltf-transform optimize input.glb output.glb

# Or step by step for control:

# 1. Deduplicate accessors and textures
gltf-transform dedup input.glb deduped.glb

# 2. Draco-compress geometry (80-90% size reduction)
gltf-transform draco deduped.glb compressed.glb

# 3. Resize textures (max 1024px for web)
gltf-transform resize compressed.glb resized.glb --width 1024 --height 1024

# 4. Convert textures to WebP (30-50% smaller than JPEG)
gltf-transform webp resized.glb final.glb --quality 80

# 5. Convert to KTX2 for GPU-compressed textures
gltf-transform ktx2 resized.glb final-ktx2.glb --compress uastc

Before/after file sizes from a real asset pipeline:

That is a 95% reduction. The visual difference at web viewport sizes is negligible.

Draco Compression

Draco (Google's geometry compression) reduces geometry data by 80-90%. Three.js includes a DracoLoader that decompresses on the client.

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';
import { DRACOLoader } from 'three/addons/loaders/DRACOLoader.js';

const dracoLoader = new DRACOLoader();
dracoLoader.setDecoderPath('/draco/');
dracoLoader.preload();

const gltfLoader = new GLTFLoader();
gltfLoader.setDRACOLoader(dracoLoader);

gltfLoader.load('/models/product.glb', (gltf) => {
  scene.add(gltf.scene);
});

KTX2 and GPU-Compressed Textures

Standard textures (JPEG, PNG, WebP) decompress to raw RGBA on the GPU. A 1024x1024 JPEG that is 200KB on disk becomes 4MB in GPU memory. KTX2 uses GPU-native compression formats (UASTC, ETC1S) that stay compressed in GPU memory.

import { KTX2Loader } from 'three/addons/loaders/KTX2Loader.js';

const ktx2Loader = new KTX2Loader();
ktx2Loader.setTranscoderPath('/basis/');
ktx2Loader.detectSupport(renderer);

gltfLoader.setKTX2Loader(ktx2Loader);

KTX2 earns its complexity when a scene loads dozens of textures at once (product configurators with material variants, digital twins with detailed environments). For a single-model scene with two or three textures, the extra build step rarely pays for itself.

Texture Budgets

Pick a resolution from the rendered size of the object, not the source file. The table below is the starting point we reach for; drop a tier whenever the object sits further from the camera.

The rule: size textures for their rendered size, not their source size. A texture that never renders larger than 256 pixels on screen should not be 2048 pixels in the file.

Progressive Loading

A single monolithic file makes users wait. Progressive loading shows content immediately and refines it as more data arrives.

// Progressive loading with priority
async function loadModel() {
  // Phase 1: skeleton (instant feedback)
  const skeleton = await gltfLoader.loadAsync('/models/product-skeleton.glb');
  scene.add(skeleton.scene);

  // Phase 2: base model (replaces skeleton)
  const base = await gltfLoader.loadAsync('/models/product-base.glb');
  scene.remove(skeleton.scene);
  scene.add(base.scene);

  // Phase 3: high-res textures (background upgrade)
  const textures = await Promise.all([
    textureLoader.loadAsync('/textures/product-diffuse-2k.webp'),
    textureLoader.loadAsync('/textures/product-normal-2k.webp'),
  ]);
  base.scene.traverse((child) => {
    if (child.isMesh && child.material.map) {
      child.material.map = textures[0];
      child.material.normalMap = textures[1];
      child.material.needsUpdate = true;
    }
  });
}

For product configurators, load the base model and default material first. Variant materials load on demand when the user selects them. For digital twins, load the building structure first, then equipment, then data overlay.

Model Preparation Checklist

Run through this before every export. Most pipeline problems are authoring problems that compression cannot fix, so a clean source file is worth more than any single optimisation flag.

Geometry hygiene

These four decide how much there is to compress in the first place. Get them wrong and you are compressing waste.

• Remove hidden geometry that the camera will never see (internal faces, back panels against walls).
• Merge objects that share a material and will never be individually selected.
• Apply all modifiers (subdivision surface, mirror, array, bevel).
• Check normals are consistent, using Blender's face orientation overlay.

Runtime readiness

The rest are about making the asset safe to use in code and predictable to ship.

• Name every mesh and material for runtime access via getObjectByName().
• Remove unused data (materials, textures, vertex groups, shape keys).
• Verify triangle count is within budget, using Blender's stats overlay.
• Test on a real device at target texture resolution before exporting at full res.

The Business Link

None of this is visible in a screenshot. It shows up the moment a real customer opens the page on a three-year-old phone on a train. The pipeline is the difference between a product they wait for and one they abandon.

The pipeline runs once per asset update. The performance benefit is permanent. A day spent on asset optimisation can save every user five or ten seconds on every visit. Across a thousand daily users, that is hours of waiting removed each week, traded for a single day of work.