WebGPU is the successor to WebGL. After years of development, it reached production readiness across all major browsers in late 2025 (Chrome 113+, Firefox 118+, Safari 26). Three.js supports WebGPU via WebGPURenderer, importable with zero configuration since r171. This is not a future technology. It is deployable now.
The performance gains are real, particularly for GPU-bound applications and compute shaders. The migration path from WebGL is straightforward for standard scenes but requires attention for custom shaders, post-processing pipelines, and advanced rendering techniques.
Migration Readiness Check
Answer five questions about your current Three.js setup. The assessment recommends whether to stay on WebGL, prepare for WebGPU, or migrate now, based on where the performance gains actually apply.
The Constraint: Two Rendering APIs
WebGL maps to OpenGL ES 2.0/3.0. Well-understood, universally supported, thoroughly optimised, and feature-frozen for years. WebGPU maps to modern GPU APIs (Vulkan, Metal, DirectX 12). Lower-level GPU control, compute shaders, better multi-threaded rendering, more efficient state management. Both exist simultaneously, and you cannot assume all users have WebGPU.
API Coexistence
WebGL is not going away. WebGPU adds capability, it does not replace infrastructure. Applications need to support both APIs during the transition period, which may last years.
Fallback Reality
Corporate environments with locked browsers, older mobile devices, and embedded WebViews still lack WebGPU. Production applications need feature detection and graceful fallback to WebGL.
The Naive Approach
The tutorial migration: swap the renderer and ship. This works for the demo but breaks in production.
Feature Detection and Fallback
Check for WebGPU support and fall back to WebGL. Three.js abstracts most differences between the two renderers. Standard materials (MeshStandardMaterial, MeshPhysicalMaterial), lights, shadows, and camera controls work identically on both. The same scene graph renders on either renderer without code changes.
Detection pattern: const renderer = navigator.gpu ? new WebGPURenderer({ canvas }) : new WebGLRenderer({ canvas }); Three.js handles the rest. Scene, camera, materials, and controls work across both renderers without changes.
The exception: custom shaders. GLSL shaders (used with ShaderMaterial or RawShaderMaterial in WebGL) must be rewritten in WGSL for WebGPU. Three.js's Node Material system provides a renderer-agnostic alternative: define materials as a node graph, and Three.js compiles to the appropriate shading language.
When WebGPU Helps (and When It Does Not)
WebGPU provides measurable improvements in specific scenarios. For everything else, WebGL performs equivalently or better.
| Scenario | WebGPU advantage | WebGL verdict |
|---|---|---|
| 10,000+ draw calls | Command buffer batching: 20-40% faster | Per-call overhead adds up |
| Physics / particles / layout | Compute shaders: GPU-side, no render workaround | CPU only or hack via render-to-texture |
| Multi-pass post-processing | Explicit pipeline state, less overhead | Works fine for standard chains |
| Under 1,000 draw calls | No measurable difference | Simpler, universal support |
| Existing GLSL shaders | Requires WGSL rewrite | Keep what works |
| Corporate / locked browsers | May not be available | Universal support |
If the application already hits 60fps on target devices, WebGPU adds complexity without measurable benefit. Profile before migrating.
Node Material System
Three.js's TSL (Three.js Shading Language) / Node Material system is the renderer-agnostic approach to custom materials. Instead of writing GLSL or WGSL directly, you define materials as a graph of nodes (operations). Three.js compiles the graph to the appropriate shading language for whichever renderer is active.
Renderer-Agnostic Shading
Node materials compile to GLSL for WebGL and WGSL for WebGPU. The same material definition works on both renderers. This is the recommended approach for new projects that want WebGPU compatibility without vendor lock-in.
Trade-off: node materials are more abstract than raw shader code. Complex effects that rely on specific GLSL features may need workarounds. For most production use cases (custom colour mapping, data-driven vertex displacement, procedural textures), node materials are sufficient.
Compute Shaders
The biggest architectural addition in WebGPU. Compute shaders run on the GPU but do not render anything. They process data in parallel, reading from and writing to GPU buffers. This opens categories of work that previously required CPU computation or GPU rendering workarounds.
Particle Simulation
Move thousands of particles per frame based on forces, collisions, and user interaction. The GPU processes all particles in parallel. Results stay on the GPU for rendering, avoiding the CPU-GPU round-trip entirely.
Force-Directed Layout
The force simulation for network graphs runs on the GPU. Barnes-Hut force calculation parallelises well. Thousands of nodes update positions in a single compute pass.
Data Transformation
Filter, aggregate, or transform large datasets on the GPU before rendering. A dataset of 1,000,000 points filtered to 10,000 visible points in a compute pass, with only the visible points rendered.
Image and Texture Processing
Generate procedural textures, apply filters, or process heightmaps on the GPU. Useful for dynamic terrain in geospatial visualisation.
Performance insight: Data that stays on the GPU avoids the CPU-GPU transfer bottleneck. If compute output is used only for rendering (particle positions, vertex colours), keep it in GPU buffers and bind directly to the render pipeline.
Compute Architecture Pattern
The compute pipeline follows four stages. The key decision is step 4: whether results need to come back to the CPU or can stay on the GPU for rendering.
Upload data to a GPU storage buffer. This is the initial transfer from CPU to GPU memory.
Define the compute shader that reads input, processes it, and writes output. Workgroup size determines parallelism granularity.
Dispatch the compute shader with a workgroup count appropriate for the data volume. The GPU executes the shader in parallel across workgroups.
Read results back to the CPU (for application logic) or keep them on the GPU (for direct rendering). The GPU-only path eliminates the transfer bottleneck.
Migration Checklist
For existing Three.js applications moving from WebGL to WebGPU. Each step is independently testable. Stop at any point if the results are not what you need.
Update Three.js
To r171 or later. WebGPURenderer is included in the standard build. No additional packages required.
Replace Renderer Initialisation
Add feature detection and fallback. Use the navigator.gpu check pattern. Keep WebGLRenderer as the fallback path.
Test Standard Materials
MeshStandardMaterial, MeshPhysicalMaterial, and all built-in materials should work without changes. Verify lighting and shadows render correctly.
Audit Custom Shaders
Any ShaderMaterial or RawShaderMaterial with inline GLSL needs conversion to WGSL or migration to node materials. This is typically the largest migration effort.
Audit Post-Processing
EffectComposer and post-processing passes may need WebGPU-compatible alternatives. The Three.js postprocessing module is adapting; check compatibility for each pass.
Test on Target Devices
WebGPU performance varies by GPU vendor and driver version. Test on real hardware, not just your development machine. Include mobile devices in testing.
Profile and Compare
Compare frame times on WebGL and WebGPU for your specific scene. If WebGPU is not faster for your workload, there is no urgency to migrate.
WebGL vs WebGPU
A direct comparison of the two rendering APIs as they relate to Three.js application development.
| Aspect | WebGL | WebGPU |
|---|---|---|
| Shading language | GLSL (ES 1.0 / 3.0) | WGSL |
| Compute shaders | Not available | Full support |
| API model | Immediate mode | Command buffer |
| Draw call efficiency | Per-call overhead | Batched submission |
| Browser support | Universal | All major browsers (2025+) |
| Three.js integration | WebGLRenderer (mature) | WebGPURenderer (stable since r171) |
| Memory management | Implicit | Explicit control |
| Best for | Broad compatibility, simple scenes | High draw counts, compute, complex pipelines |
The Business Link
WebGPU is not a mandatory upgrade. WebGL continues to work and will be supported for years. The reason to adopt WebGPU is specific: your application needs compute shaders, your draw call count is high enough that batching provides measurable improvement, or you are building new functionality that benefits from modern GPU architecture.
Practical advice: Use the node material system for new shader work (renderer-agnostic). Implement feature detection and fallback (support both APIs). Profile before migrating existing applications. The performance gains are real but workload-dependent. Measure, do not assume.
Build for the Next GPU Generation
We build Three.js applications that take advantage of WebGPU where it matters and fall back gracefully where it does not. Compute shaders, optimised rendering pipelines, and future-proof architecture.
Let's talk about your rendering needs →