Frontend · Three.js

WebGPU in Three.js Is Production-Ready for New Projects, but Legacy Migration Is Still Brutal

By 李伟_Li慢慢 · Jul 14, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

WebGPU is the long-term replacement for WebGL in the browser, and Three.js has committed WebGPURenderer as its sole forward-looking renderer. Teams starting greenfield 3D projects today can adopt it immediately and gain access to compute shaders and hardware ray tracing, but anyone maintaining a substantial WebGL codebase faces a rewrite of every custom shader and post-processing effect.

Summary

Three.js's official WebGPURenderer has reached a state where it is usable and stable for new projects, especially those leveraging compute shaders, massive particle systems, or hardware ray tracing. Basic PBR rendering, GLTF loading, and standard controls work with an API nearly identical to WebGL. Browser support now covers all modern Chrome, Edge, Firefox, and Safari versions, plus iOS 17+ and recent Android.

However, the renderer introduces a hard break with the WebGL ecosystem. Custom GLSL ShaderMaterial, RawShaderMaterial, and onBeforeCompile hooks are completely unsupported with no automatic transpilation path. All legacy post-processing passes built on EffectComposer are dead; only the new node-based PostProcessing system works. The API is now asynchronous, requiring `await renderer.renderAsync()` and manual `renderer.init()` calls, which forces structural changes to existing render loops.

Performance pitfalls remain. First-frame cold starts can run 5–10× slower than WebGL due to WGSL pipeline compilation, and scenes with thousands of un-instanced small meshes can see higher CPU overhead from bind-group switching. Memory management is less polished, with GPU memory leaks possible under frequent create-destroy cycles. For teams with large WebGL codebases full of custom shaders and third-party plugins, the migration cost is high enough that sticking with WebGLRenderer is the pragmatic choice until the feature gap closes further.

Takeaways

— WebGPURenderer is stable for new projects using standard PBR materials, GLTF models, and basic animations, with an API surface nearly identical to WebGL.

— Custom GLSL shaders (ShaderMaterial, RawShaderMaterial, onBeforeCompile) are completely unsupported and must be rewritten in TSL or raw WGSL.

— All traditional EffectComposer post-processing passes are incompatible; only the new node-based PostProcessing system works.

— First-frame rendering can be 5–10× slower than WebGL due to WGSL pipeline compilation, especially in scenes with many independent meshes.

— Scenes with thousands of un-instanced small meshes can see higher CPU overhead than WebGL because of per-frame bind-group switching.

— Rendering is now asynchronous: `renderer.renderAsync()` replaces the synchronous `renderer.render()`, and `renderer.init()` must be awaited manually.

— Old hardware with Intel integrated graphics or outdated AMD/NVIDIA drivers can hit WGSL compilation crashes and texture corruption with no frontend fix.

— Third-party tools like stats-gl are incompatible; only the built-in Inspector performance panel works with WebGPU.

— GPU memory leaks are possible under frequent create-destroy cycles because automatic reclamation is less mature than in WebGL.

— WebGL is not being deprecated, but WebGPURenderer is the only renderer receiving long-term feature development from the Three.js team.

Conclusions

WebGPU's adoption path in Three.js mirrors the OpenGL-to-Vulkan transition in native graphics: a clean break with legacy shader infrastructure that forces a rewrite but unlocks modern GPU features.

The lack of GLSL-to-WGSL transpilation is a deliberate design choice, not an oversight. Early auto-transpilation was removed, signaling that the team sees TSL as the strategic material authoring layer going forward.

The 5–10× first-frame slowdown is a real production concern for interactive applications, not just a benchmark footnote. Any app that dynamically creates many objects will feel this as user-visible jank.

WebGPU's performance advantage only materializes in GPU-bound, highly parallel workloads. For CPU-bound scenes with many draw calls, WebGL's mature driver optimizations still win, which inverts the common assumption that WebGPU is always faster.

The async render API is the most underappreciated migration cost. It doesn't just change a function signature; it forces asynchronous thinking into every part of the application that touches rendering, from loaders to UI feedback loops.

Concepts & terms

TSL (Three.js Shading Language)

A node-based material authoring system in Three.js that compiles to both GLSL and WGSL, intended as the unified replacement for hand-written shader code across WebGL and WebGPU backends.

WGSL (WebGPU Shading Language)

The native shading language of WebGPU, analogous to GLSL for WebGL but designed for the modern GPU pipeline. Three.js allows writing raw WGSL via RawWGSLMaterial.

Bind Groups

WebGPU's mechanism for grouping and binding resources (buffers, textures, samplers) that a shader will access. Switching bind groups per draw call adds CPU overhead that WebGL's implicit state model avoided.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗