WebGPU vs WebGL: Which Should You Use in Three.js?

WebGL wraps OpenGL ES for the browser. It was designed in 2011 around a graphics model that was already old then, and it has no first-class support for compute shaders; general-purpose GPU work has to be smuggled through vertex/fragment tricks.

WebGPU is a new API designed against modern native graphics APIs (Vulkan, Metal, Direct3D 12). The changes that matter in practice:

• Compute shaders. WebGPU can run arbitrary GPU compute passes, not just rasterize triangles. Particle systems, physics, and GPGPU-style simulation move from "hacks in a fragment shader" to first-class code.
• Lower CPU overhead. WebGPU's command-buffer model front-loads validation, so draw calls are cheaper at runtime. Scenes with many draw calls or frequent state changes benefit the most.
• A real shading language. WebGPU shaders are written in WGSL. Three.js does not ask you to write WGSL by hand. It gives you TSL (Three.js Shading Language), a JavaScript-like node system that compiles down to WGSL for WebGPU and to GLSL for WebGL, so one shader graph targets both renderers.
• Explicit resource management. Buffers, textures and pipelines are created and bound explicitly, which is more verbose at the raw API level but is exactly what WebGPURenderer abstracts away for you.

What did not change: your scene graph, your materials API surface, your camera and control code. If you already know Three.js, switching renderers is mostly a rendering-backend decision, not a rewrite.

WebGPU shipped in Chrome and Edge (2023) and in Firefox and Safari more recently, but support is not yet as universal as WebGL's:

• Chrome, Edge, Opera (desktop & Android): full support.
• Safari: supported in recent macOS/iOS versions; older Safari releases still in circulation do not have it.
• Firefox: shipped behind updates that are still rolling out to all channels; check before assuming coverage.

WebGL, by contrast, runs in effectively every browser released in the last decade, including older mobile devices and embedded browsers.

This is why WebGPURenderer in modern Three.js is not an either/or choice: it detects WebGPU support at runtime and falls back to WebGL automatically when it is unavailable, using the same TSL-authored materials on both paths. That fallback is the single biggest reason most new projects should just start with WebGPURenderer rather than picking a renderer up front.

WebGPU is not "faster" in every scene. It is faster in the specific situations its design targets:

• Many draw calls / complex scenes. Lower per-draw-call CPU overhead means WebGPU pulls ahead as scene complexity grows. A simple rotating cube shows little difference; a scene with thousands of instanced objects can show a large one.
• Compute-bound effects. Particle systems, fluid simulation, GPU-driven culling and skinning, and anything else that benefits from a real compute shader, run meaningfully better on WebGPU because there is no fragment-shader workaround involved.
• Simple scenes. For a handful of meshes and standard materials, the two renderers perform comparably; the bottleneck is elsewhere (fill rate, texture bandwidth, JavaScript).

In short: WebGPU's ceiling is higher, but it only shows up once you hit the kind of complexity WebGL's model struggles with.

Start with WebGPURenderer when:

• You're starting a new project today. The automatic WebGL fallback means there is little downside.
• You need compute shaders, such as particles, simulations, or GPGPU work, where TSL's node system pays off immediately.
• You're already using or learning TSL, since TSL material graphs work on both backends.

Reach for plain WebGLRenderer when:

• You depend on a library or post-processing pass that has not been ported to WebGPURenderer/TSL yet. Check the ecosystem first.
• You need guaranteed behaviour on very old browsers or embedded WebViews where WebGPU has no path at all, even via fallback (rare, but it exists).
• You're maintaining an existing WebGL project where a migration isn't currently worth the risk.

If you're migrating an existing Three.js scene rather than starting fresh, see the Three.js WebGPU guide for the specifics of setting up WebGPURenderer and porting a custom ShaderMaterial to TSL. That conversion, not the renderer swap itself, is usually the bulk of the work.