Next-Generation GPU Rendering in the Browser
Three.js WebGPU support is no longer a preview. WebGPU is the successor to WebGL, and after years of development it reached production readiness across all major browsers in late 2025 (Chrome 113+, Firefox 118+, Safari 26). Three.js ships WebGPURenderer in the standard build, importable with zero configuration since r171. This isn't a future technology. You can deploy it now.
The performance gains are real, particularly for GPU-bound applications and compute shaders. The migration from WebGL is straightforward for standard scenes, but custom shaders, post-processing pipelines, and advanced rendering techniques each need attention. This page covers when the move pays off, when it doesn't, and how to do it without breaking the users who can't run WebGPU yet.
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. It's well-understood, universally supported, thoroughly optimised, and feature-frozen for years. WebGPU maps to modern GPU APIs: Vulkan, Metal, and DirectX 12. That buys lower-level GPU control, compute shaders, better multi-threaded rendering, and more efficient state management.
Both APIs exist at once. You can't assume every user has WebGPU, so the architecture has to hold up on either one.
API Coexistence
WebGL isn't going away. WebGPU adds capability, it doesn't 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.
Those two assumptions cost time. The next two cost reach: they quietly drop users and leave the best part of WebGPU on the table.
Feature Detection and Fallback
Check for WebGPU support and fall back to WebGL. Global WebGPU support sits at roughly 70 to 80 percent of browsers as of early 2026, so a production application still can't assume every visitor has it. 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.
There is one migration trap worth flagging before you start, because it catches more teams than the renderer swap does.
Post-processing is the usual blocker. WebGPURenderer doesn't run the legacy EffectComposer or its effect passes. Three.js provides a new node-based post-processing stack built on TSL, but it doesn't yet have the full ecosystem of ready-made passes the old system had. In our experience, a migration that touches bloom, SSAO, depth of field, or colour grading needs each pass checked, and often rewritten, against the new pipeline. Budget for it rather than discovering it mid-migration.
Compute Shaders
This is the biggest architectural addition in WebGPU. Compute shaders run on the GPU but don't render anything. They process data in parallel, reading from and writing to GPU buffers. That opens up categories of work that used to need CPU computation or awkward 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 reshape large datasets on the GPU before rendering. A dataset of 1,000,000 points filtered to 10,000 visible points in a single compute pass, with only the visible points sent to the renderer. This is the pattern behind responsive 3D data visualisation at scale.
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.
Steps 1 and 2 are setup. The next two are where the work actually runs and where the GPU-versus-CPU decision is made.
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 isn't faster for your workload, there's no urgency to migrate.
WebGPU vs WebGL for Three.js
A direct comparison of the two rendering APIs as they relate to Three.js WebGPU development. The differences below are the ones that change how you architect an application, not a full spec table.
| 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 isn't a mandatory upgrade. WebGL keeps working 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 gives a measurable improvement, or you're 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, don't 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 doesn't. Compute shaders, optimised rendering pipelines, and architecture that holds up as browser support fills in.
Let's talk about your rendering needs →