Three.js in Production 2026: WebGPU, Perf & Fallback

Q: Why does my Three.js scene run fast in development but slow in production?

Because the development environment hides almost every production performance problem. In development you run one hand-optimized scene on a fast developer laptop with a discrete or high-end integrated GPU, a warm asset cache, and usually just the 3D view open with nothing else competing for the GPU. Production inverts all of that: assets load over real, variable networks; the code runs on the devices your users actually own, which skew toward four-year-old mid-range Android phones with weak GPUs; the 3D view runs alongside the rest of your application competing for memory and GPU time; and the user navigates in and out of the view repeatedly, which exposes memory leaks that a single-load demo never triggers. The specific killers, in rough order of how often they surprise teams: draw-call count (a scene of hundreds of separately-added meshes stalls on command overhead regardless of triangle count), GPU memory leaks (Three.js does not free geometries, materials, and textures automatically, so mounting and unmounting a view without disposing leaks until the tab crashes), uncompressed assets (a 40MB model that loads instantly on wifi is a 40-second wait on mobile data), and fill-rate limits from overdraw and transparency that a desktop GPU absorbs but a mobile GPU chokes on. The fix is not a faster shader; it is profiling on the actual target device and applying the boring production discipline the demo let you skip.

Q: How do I stop Three.js from leaking memory?

By explicitly disposing every GPU resource when it is no longer needed, because Three.js deliberately does not do this for you. Unlike JavaScript objects that the garbage collector reclaims, GPU resources — geometries, materials, textures, render targets — live in graphics memory that the browser's garbage collector cannot see or free, so Three.js exposes a .dispose() method on each and leaves the calling of it to you. The leak pattern that ships to production constantly: a single-page application mounts a 3D view, the user navigates away, the view unmounts, and the code drops its references to the scene without disposing the underlying GPU resources — the JavaScript objects get collected but the GPU memory does not, so every visit to that view leaks a little more until the tab slows to a crawl and eventually crashes, which surfaces as the classic bug report "the app gets slower the longer I use it." The discipline: on teardown, traverse the scene and call .dispose() on every geometry, every material (and every texture the material references), and any render targets, then remove objects from the scene graph. Textures are the biggest offenders because they are large and easy to forget. If you are in React, React Three Fiber automates much of this by tying resource lifecycles to component lifecycles, which is one of the strongest reasons to use it in production rather than hand-rolling the scene graph — hand-rolled Three.js is where disposal is most often forgotten. Verify with the browser's memory profiler: navigate in and out of the 3D view repeatedly and confirm GPU memory returns to baseline rather than climbing.

Q: What is WebGPU and should I use it in Three.js in 2026?

WebGPU is the modern successor to WebGL — a new browser graphics API with lower driver overhead, more explicit control over the GPU, and, most importantly, compute shaders, which let you run general-purpose parallel work (particle systems, physics simulation, procedural generation) directly on the GPU instead of forcing it onto the CPU as WebGL did. Three.js ships a WebGPURenderer alongside its classic WebGLRenderer, and on supporting hardware the throughput improvement is substantial, not marginal, which makes 2026 a genuine reason to revisit Three.js. Whether to use it depends entirely on how you ship it, because two facts govern the decision. First, browser and device support is broad but not universal: recent Chrome and Edge have solid support, Safari and Firefox are increasingly there, but the long tail of older devices and browsers does not support it, and those devices are exactly the mid-range phones much of your audience uses. Second, the specification is still hardening at the edges, so some advanced features behave inconsistently across implementations. The correct production pattern is therefore not "switch to WebGPU" but capability detection with graceful degradation: attempt to create a WebGPURenderer, fall back to WebGLRenderer when WebGPU is unavailable, and fall back once more to a static poster image when the device supports neither — because a 3D feature that renders a blank canvas is strictly worse than one that renders a picture. Used this way, WebGPU is a clear yes: you get the performance and compute-shader capabilities on the devices that support them while never breaking the experience for the devices that do not. Used as a hard requirement, it silently breaks your feature for a meaningful slice of real users.

Q: What is the biggest Three.js performance killer?

For most real scenes, the draw-call count — not the triangle count, which is what teams instinctively worry about. A draw call is a command to the GPU to render something, and issuing many separate commands carries per-call overhead on the CPU-to-GPU path that stalls the pipeline long before raw polygon throughput becomes the limit. A scene with a few hundred individually-added meshes, each its own material, issues a few hundred draw calls per frame and will struggle to hold 60fps on mobile even if the total polygon count is modest, while a scene with the same polygons consolidated into a handful of draw calls runs comfortably. The three fixes, applied by scene type: instanced rendering (InstancedMesh) for many copies of the same geometry — trees, crowd, particles, repeated UI elements — which renders thousands of instances in a single draw call; merged geometry (BufferGeometryUtils) for many distinct but static objects that never move independently, combining them into one geometry and one draw call; and texture atlases so that objects sharing an atlas can share a material and batch together rather than forcing a material switch (which breaks batching) per object. Beyond draw calls, the secondary killers are overdraw and fill rate on mobile (many transparent layers or full-screen post-processing effects make the GPU shade the same pixels repeatedly, which desktop GPUs absorb and mobile GPUs choke on) and uncompressed assets bloating load time and memory. But the first profiling question for a janky Three.js scene should always be: how many draw calls per frame? The renderer exposes this (renderer.info.render.calls), and the number is usually the story.

Q: How do I make Three.js work on mobile devices?

Design for the mid-range Android phone as the honest baseline, not the developer's flagship, and apply mobile-specific discipline on top of the general production checklist. The device reality: a large share of your users are on phones with weak GPUs, limited memory, thermal throttling under sustained load, and mobile data caps, and a scene that flies on a desktop GPU can be unusable there. The mobile-specific priorities. Fill rate is the mobile killer that desktop hides: mobile GPUs have far less pixel-shading throughput, so overdraw from stacked transparent layers and full-screen post-processing effects tanks the frame rate — minimize transparency, avoid heavy post-processing, and consider rendering at a lower internal resolution and upscaling. Memory is tighter: dispose aggressively (leaks that merely slow a desktop crash a phone), use KTX2 compressed textures which stay compressed in GPU memory rather than decompressing like PNG/JPG, and provide lower-detail LOD models for distant or mobile contexts. Load weight matters more: compress geometry with Draco or Meshopt, lazy-load the 3D bundle and assets so the initial page is not carrying megabytes users may never see, and show a lightweight poster while assets stream. Thermal and battery: sustained 60fps 3D drains battery and triggers throttling, so cap the frame rate where the experience allows, pause rendering when the view is offscreen or the tab is hidden, and respect prefers-reduced-motion by offering a static frame. And always test on a real mid-range device, not a desktop browser's mobile emulator, which reproduces the viewport but not the GPU — the emulator will happily run a scene that the actual phone cannot.

Q: Can AI write production-ready Three.js code?

Frontier models write competent, runnable Three.js scenes from a natural-language description, which is a real productivity unlock — but "runnable and impressive" is not "production-ready," and the gap between them is exactly the discipline this article is about. What AI does well in 2026: generate a complete scene from a prompt ("a slowly rotating low-poly planet with an orbiting satellite over a starfield"), produce the boilerplate that used to consume the first day of a 3D project (renderer setup, camera, lights, animation loop), and iterate on the look through conversation faster than hand-coding. What AI-generated Three.js reliably gets wrong, because it optimizes for looking right in the immediate output rather than surviving production: it tends to add many separate meshes rather than instancing or merging (a draw-call problem), it almost never includes disposal logic (a memory leak the moment the view unmounts), it uses uncompressed assets and full-resolution textures (load-weight and memory problems), and it does not include a WebGPU/WebGL fallback or reduced-motion handling (it targets the environment it was asked about, usually latest Chrome on a fast machine). The workflow that actually works treats AI as the scene generator and the human as the production engineer: use the model to create the scene and iterate on the aesthetic quickly, then apply the production pass deliberately — instance the draw calls, add full disposal on teardown, compress the assets and add LODs, wire the renderer fallback, handle reduced-motion. This is not a limitation to lament; it is a division of labor. The AI removes the tedious authoring and lets you spend your time on the engineering that determines whether the beautiful scene ships at 60fps on the devices your users own, which was always where the real work lived.

Q: Should I use React Three Fiber or plain Three.js for production?

If your application is already React, use React Three Fiber for production; if it is not, use plain Three.js, and in both cases the underlying performance disciplines are identical. React Three Fiber is a React renderer for Three.js: instead of imperatively building and mutating the scene graph, you describe it declaratively as React components, and the library reconciles that description with Three.js under the hood. The production advantages in a React app are real and specific. Resource lifecycle management is the biggest: because Three.js objects are tied to component lifecycles, mounting and unmounting a component disposes its GPU resources automatically, which eliminates the single most common Three.js production bug — forgotten disposal and the resulting memory leak — that hand-rolled scene graphs get wrong constantly. It also composes cleanly with the rest of a React application (state, hooks, the component ecosystem via drei), which matters when the 3D view is one part of a larger app rather than a standalone canvas. The costs to weigh: a thin abstraction layer over Three.js (negligible runtime overhead but a concept to learn), and the need to understand both React's reconciliation model and Three.js underneath, because performance problems still require Three.js-level knowledge to diagnose — R3F does not remove the need to understand draw calls, instancing, and the frame budget. For a non-React application, plain Three.js is the right choice and R3F would mean adopting React solely for the 3D view, which is rarely worth it. The decision is essentially your app's existing framework: React app, R3F; anything else, plain Three.js with disciplined manual disposal.

Q: What web standards should a production Three.js feature respect?

The same standards that govern any responsible web feature, which a 3D canvas is unusually prone to violating because it is an opaque rendering surface. Accessibility first: a canvas is a black box to screen readers, so any information the 3D view conveys must have a text alternative, and interactive 3D controls need keyboard-accessible equivalents — a 3D product configurator that only works by dragging the canvas excludes keyboard and assistive-technology users entirely. Motion sensitivity: the prefers-reduced-motion media query exists because auto-playing motion causes genuine physical discomfort (nausea, vertigo) for a real portion of users, so a production 3D feature must detect it and offer a static frame or drastically reduced motion rather than forcing the animation. Performance as a standard: the 3D bundle (Three.js itself is several hundred kilobytes before your scene) must be code-split and lazy-loaded so users who never open the 3D view never download it, and the feature must not block the main thread or degrade the rest of the page — a 3D view that janks the whole application fails the standard even if the 3D itself looks good. Progressive enhancement: the feature must degrade gracefully across the capability spectrum (WebGPU to WebGL to static poster), so the experience works, in some form, everywhere rather than breaking below the latest hardware. Battery and thermal responsibility: pause rendering when the view is offscreen or the tab is backgrounded, and cap frame rates where the experience allows, because a 3D feature that silently drains battery is a standard violation users feel even if they cannot name it. These are not gold-plating; they are the difference between a 3D feature that is a responsible part of a web application and one that is a demo someone shipped.