Fix Three.js & React Three Fiber performance

The three causes of a slow Three.js or R3F scene

When a ThreeJS scene drops frames or performs poorly on mobile, the root cause is almost always the loaded model, not the render loop. Three.js and R3F are efficient renderers; they struggle when the assets they are given are too heavy. Before reaching for profiler counters or useFrame optimizations, inspect the model itself.

Draw calls are the first thing to measure. Every mesh with its own material generates a separate draw call — a CPU-to-GPU command with non-trivial overhead per frame. A single model exported from CAD or a sculpting tool can contain hundreds of meshes with individual materials, producing hundreds of draw calls per frame. On mobile, draw calls above ~50 become a significant CPU bottleneck regardless of GPU speed. Merge geometries that share a material using mergeGeometries from three-stdlib, and consider InstancedMesh for repeating objects to collapse many draw calls into one.

Uncompressed textures are the second lever. A PNG or JPEG texture must be fully decoded into GPU memory before it can be used. A single 4096×4096 RGBA texture consumes ~64 MB of VRAM — before mipmaps. Three or four maps of that size exhaust the VRAM budget on most mobile devices, causing texture loss, frame drops, or tab crashes. KTX2 (Basis Universal) solves this: the texture stays compressed natively on the GPU, reducing VRAM by 4–6×. Three.js ships a KTX2Loader that handles format transcoding automatically.

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

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

const loader = new GLTFLoader();
loader.setKTX2Loader(ktx2Loader);

Draco compression: smaller geometry, faster parse

If the GLB uses Draco geometry compression — which it should, for any production asset — you need to configure the DRACOLoader on the GLTFLoader. Without it, Three.js cannot parse Draco-compressed meshes at all. With it, geometry that was 20 MB on disk loads as 3 MB and parses significantly faster.

The MeshGrade analyzer reports whether Draco and KTX2 compression are present in your GLB. If they are not, that is almost always the highest-impact change available. A model that goes from uncompressed to Draco + KTX2 typically drops from 20–40 MB to 2–5 MB with no visible quality change.

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

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

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

Measure first — then optimize

Before writing any of the above, run your model through the free MeshGrade analyzer. It reports the exact draw call count, triangle and vertex totals, every texture's resolution and estimated VRAM cost, and whether Draco and KTX2 compression are present. A five-second grade tells you whether the bottleneck is draw calls, texture memory, or geometry density — so you invest your optimization time in the right place and skip changes that won't move the needle.