Three.js Performance Optimization

Reference Files

• instancing-static.md

  — InstancedMesh for large static repeated objects (19,600 → 1 draw call)

• instancing-moving.md

  — Flat state buffer + batched InstancedMesh writes for moving entities (8,000 entities)

• templates/

  — Baseline vs optimized reference implementations for each pattern

When to Use This Skill

• Scene has 100+ repeated objects sharing geometry/material
• Draw calls exceed 500 and frame time is unstable
• Thousands of moving entities need per-frame transform updates
• Profile shows scene-graph traversal as a bottleneck

When NOT to Use

• Object count is low (<50 unique meshes) — simpler code wins
• Every object needs unique materials/shaders that defeat batching
• Geometry differs enough that instancing provides no batching benefit

Pattern 1: Instancing Large Static Object Sets

InstancedMesh

instancing-static.md

// Anti-pattern: one Mesh per prop
for (let i = 0; i < 19600; i++) {
  const mesh = new THREE.Mesh(geometry, material);
  mesh.position.set(x, 0, z);
  scene.add(mesh); // 19,600 draw calls
}

// Correct: one InstancedMesh
const im = new THREE.InstancedMesh(geometry, material, 19600);
const mat = new THREE.Matrix4();
for (let i = 0; i < 19600; i++) {
  mat.makeTranslation(x, 0, z);
  im.setMatrixAt(i, mat);
}
im.instanceMatrix.needsUpdate = true;
scene.add(im); // 1 draw call

Pattern 2: Moving Entity Update Loops

InstancedMesh.setMatrixAt()

instancing-moving.md

// Anti-pattern: per-entity Mesh position writes
meshes.forEach((mesh, i) => {
  mesh.position.x = computeX(i, tick);
  mesh.position.y = computeY(i, tick);
});

// Correct: batched instance matrix writes
const mat = new THREE.Matrix4();
for (let i = 0; i < count; i++) {
  mat.makeTranslation(computeX(i, tick), computeY(i, tick), computeZ(i, tick));
  instancedMesh.setMatrixAt(i, mat);
}
instancedMesh.instanceMatrix.needsUpdate = true;

Decision Tree

Is the object repeated 50+ times with same geometry+material?
├── YES → Is it static (no per-frame movement)?
│   ├── YES → Pattern 1: Static InstancedMesh (instancing-static.md)
│   └── NO  → Pattern 2: Moving InstancedMesh with batched writes (instancing-moving.md)
└── NO  → Standard Mesh is fine. Focus on material/geometry reuse.

Measured Results

Methodology notes

• CPU-side metrics are the trustworthy signal. Draw calls, render CPU p95, update loop, and build time reliably show the 1–2 order-of-magnitude win.
• FPS and frame-time p95 are unreliable in headless Chromium. Playwright's bundled Chromium uses SwiftShader (software WebGL), which bottlenecks on fragment shading of ~90 MB of visible geometry regardless of draw-call count. On real hardware WebGL, the FPS gap would be substantially larger — baseline would drop to single-digit FPS under real fill, and optimized would hit vsync cleanly.
• A benchmark passes if draw calls decreased and render CPU p95 did not regress.