WebGPU, Real-Time 3D Beyond the Creative Studios
WebGPU now draws in Chrome, Safari and Firefox, iPhone included. Its real usage grew sevenfold in a year. This article gives the starter code, the WebGL fallback and what studies measure about 3D in e-commerce.
On 30 September 2026, 0.40% of pages loaded in Chrome open a WebGPU canvas, according to Chrome's usage counters (opens in a new tab). A year earlier the share was 0.05%. WebGL, the web's long-standing 3D interface, is still present on 27% of page loads (opens in a new tab). The gap remains wide but WebGPU usage has grown more than sevenfold in twelve months.
WebGPU is the interface that gives a web page access to the device's graphics processor, the GPU. It succeeds WebGL, published in 2011. Chrome has enabled it since version 113 (opens in a new tab) on desktop, released in spring 2023. The main barrier fell on 15 September 2025, when Safari 26 (opens in a new tab) shipped it on macOS, iOS, iPadOS and visionOS. Since that date, a 3D scene written for WebGPU renders on an iPhone.
Real-time 3D has long been associated with creative studio websites, award-winning and heavy. The uses growing with WebGPU are more ordinary. They include a product configurator, a design tool such as Figma or an AI model running in the browser. Libraries have absorbed most of the complexity. Three.js picks between WebGPU and WebGL on its own depending on the device, which reduces the support question to one import line.
What WebGPU changes compared with WebGL
WebGL derives from OpenGL ES, a graphics interface designed before today's graphics processors. Operating systems have since moved to other interfaces, Metal at Apple, Direct3D 12 at Microsoft and Vulkan on Android and Linux. Every WebGL call therefore has to be translated. The WebKit team says so in its Safari 26 announcement. WebGPU "maps better to Metal, and the underlying hardware", whereas WebGL required significant translation overhead.
Three differences matter for a web project.
- General-purpose computation. A compute shader is a program the graphics processor runs without drawing anything. It processes data in parallel for a particle simulation, physics, image processing or running an AI model. WebGL did not allow it. Developers had to draw triangles to trigger a computation (opens in a new tab) then pack the data into textures
- Render preparation. Graphics settings are described once in an object called a pipeline then reused. The browser has fewer checks to repeat on every frame
- The shader language. WGSL, short for WebGPU Shading Language, replaces GLSL. It is identical across all browsers and all operating systems
Speed gains depend on what the application does and the published figures cover specific cases. Babylon.js submits a static scene more than ten times faster (opens in a new tab) thanks to a WebGPU feature that records draw commands and replays them. That gain concerns the work done by the central processor. The available graphics power stays the same. A TensorFlow.js image generation model ran three times faster after moving from WebGL to WebGPU, according to the same source.
Figma, which migrated its rendering engine to WebGPU (opens in a new tab) in 2025, reports an improvement on some classes of devices, neutral results on others and no regressions. Moving to WebGPU therefore does not automatically speed up an existing scene. The benefit shows on scenes with many objects and on computations WebGL could not perform.
WebGPU browser support in October 2026
WebGPU works in all three browser engines, with gaps depending on the operating system.
| Browser | Since | Coverage |
|---|---|---|
| Chrome and Edge on desktop | Version 113, spring 2023 | Windows, macOS and ChromeOS. Linux since version 144 for recent Intel chips, 147 for NVIDIA |
| Chrome on Android | Version 121, January 2024 | Android 12 and later, Qualcomm and ARM chips |
| Safari | Version 26, September 2025 | macOS, iOS, iPadOS and visionOS in their version 26 |
| Firefox | Version 141, July 2025 | Windows. Apple silicon Macs since versions 145 and 147. Neither Linux nor Android |
WebGPU support by browser and operating system in October 2026
The dates come from the Chrome announcements for Android (opens in a new tab) and for Linux (opens in a new tab), from WebKit (opens in a new tab), from Mozilla (opens in a new tab) and from the MDN compatibility table (opens in a new tab).
These gaps explain the official status. WebGPU is still rated Baseline "limited availability" (opens in a new tab), the level given to a feature that is still missing from part of the reference browsers. Can I Use (opens in a new tab) puts the share of users whose browser fully supports it at 85.72%. The specification is not finished either. The W3C publishes it as a Candidate Recommendation Draft (opens in a new tab), a stage that comes before the final recommendation.
Three populations are left out. They are Apple devices still running an earlier version of the system, Firefox users on Linux and Android, as well as older Android phones whose chip does not handle recent graphics interfaces. For the latter, Chrome 146 introduced a compatibility mode (opens in a new tab) in February 2026 that runs WebGPU on OpenGL ES 3.1, starting with Android. It is requested explicitly with requestAdapter({ featureLevel: "compatibility" }).
Measuring adoption calls for one precaution. The counter quoted most often, the one tracking calls to requestAdapter(), reaches 11.5% of page loads (opens in a new tab) in Chrome. It counts pages that query the graphics processor, not pages that draw. A research paper posted in June 2026 (opens in a new tab), not yet peer reviewed, observes that WebGPU use at page load consists mainly of probing the adapter without starting any rendering. The figure that describes real usage is the one for WebGPU canvases, 0.40%.
Initialising WebGPU without a library
Initialisation always follows the same three steps, documented on MDN (opens in a new tab). The page requests an adapter, which represents the graphics processor. It then obtains a logical device, the object that creates resources. Finally it connects that device to a <canvas> element.
async function initWebGPU(canvas) {
if (!navigator.gpu) return null;
const adapter = await navigator.gpu.requestAdapter();
if (!adapter) return null;
const device = await adapter.requestDevice();
const context = canvas.getContext("webgpu");
context.configure({
device,
format: navigator.gpu.getPreferredCanvasFormat(),
alphaMode: "premultiplied",
});
return { device, context };
}The three initialisation steps
The two null returns do not cover the same case. navigator.gpu is missing when the browser does not know WebGPU. requestAdapter() returns null when the browser knows it but refuses to enable it on this machine, because the graphics driver is on a blocklist (opens in a new tab) or hardware acceleration is turned off. Testing only navigator.gpu therefore lets through devices on which nothing will render.
Two changes make part of the examples published before 2025 obsolete. Information about the graphics card is now read from the adapter.info property, described on MDN (opens in a new tab), since the older requestAdapterInfo() method was removed from Chrome. Since Chrome 140 (opens in a new tab), an adapter can be used only once. A second call to requestDevice() on the same adapter fails and a new adapter has to be requested.
Three.js picks between WebGPU and WebGL depending on the device
Few projects write raw WebGPU. Most go through a library and Three.js is the most installed, with 22 million downloads (opens in a new tab) on npm during the last week of September 2026. Its WebGPURenderer rendering engine is imported from three/webgpu. According to its documentation (opens in a new tab), it uses WebGPU when the browser supports it and otherwise falls back to WebGL 2.
import * as THREE from "three/webgpu";
const canvas = document.querySelector("#product-viewer");
const renderer = new THREE.WebGPURenderer({ canvas, antialias: true });
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
renderer.setSize(canvas.clientWidth, canvas.clientHeight, false);
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(
35,
canvas.clientWidth / canvas.clientHeight,
0.1,
100
);
camera.position.set(0, 1, 4);
const product = new THREE.Mesh(
new THREE.BoxGeometry(1, 1, 1),
new THREE.MeshStandardMaterial({ color: "#c8a45a" })
);
const light = new THREE.HemisphereLight("#ffffff", "#444444", 3);
scene.add(product, light);
renderer.setAnimationLoop(() => {
product.rotation.y += 0.01;
renderer.render(scene, camera);
});A Three.js scene with WebGPURenderer
This code contains no support test. A visitor on Chrome or Safari 26 gets WebGPU, a visitor on Firefox for Linux gets WebGL 2 and the scene is the same. The forceWebGL: true option passed to the constructor makes it possible to check the fallback during development without switching machines.
One constraint sets this engine apart from the older WebGLRenderer. Its initialisation is asynchronous. The class documentation (opens in a new tab) guarantees that it is ready when rendering goes through setAnimationLoop(). In every other case, renderer.init() has to be awaited before the first call to render(). That case comes up on a configurator. Redrawing sixty times a second an image that does not change loads the graphics processor and the battery with no visible benefit. On-demand rendering draws only after an interaction.
await renderer.init();
function draw() {
renderer.render(scene, camera);
}
controls.addEventListener("change", draw);
colorPicker.addEventListener("input", (event) => {
product.material.color.set(event.target.value);
draw();
});
draw();On-demand rendering on a configurator
The renderAsync() and computeAsync() methods, found in many tutorials, have been deprecated since release r181 according to the Three.js migration guide (opens in a new tab). React Three Fiber has accepted this engine since its version 9, whose gl prop can receive an asynchronous function (opens in a new tab). The choice between Three.js, raw WebGL and an interface animation library is covered in a separate guide (opens in a new tab).
What a compute shader adds to a scene
The compute shader is the part of WebGPU with no equivalent in WebGL. The following example, written in WGSL, moves particles. Positions and velocities live in the graphics processor's memory and stay there from one frame to the next.
struct Particle {
position: vec2f,
velocity: vec2f,
}
@group(0) @binding(0)
var<storage, read_write> particles: array<Particle>;
@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) id: vec3u) {
let index = id.x;
if (index >= arrayLength(&particles)) {
return;
}
let particle = particles[index];
particles[index].position = particle.position + particle.velocity * 0.016;
}A WGSL compute shader that moves particles
Each run of main handles one particle and the graphics processor launches thousands of them in parallel, in groups of 64. In WebGL, the same update most often went through a JavaScript loop on the central processor followed by an upload of the positions on every frame. The number of particles that could be displayed was capped by that round trip. Three.js gives access to the same mechanism without writing WGSL, through TSL, its shader language written in JavaScript and imported from three/tsl.
Computation on the graphics processor is also useful outside 3D. The Transformers.js library runs AI models in the browser with the device: "webgpu" option. Its publisher Hugging Face announces execution up to 100 times faster (opens in a new tab) than with WebAssembly, a comparison between graphics processor and central processor. The figure comes from the publisher and stands as an order of magnitude for the best case.
What studies measure about 3D and sales
The most repeated figure comes from Shopify. Merchants who add 3D content to their stores "see a 94% conversion lift, on average", the platform writes in a May 2022 note (opens in a new tab). No method comes with that figure. The note specifies neither the sample nor the period nor the comparison group.
The Rebecca Minkoff case study (opens in a new tab), also published by Shopify, is more precise. Shoppers who interact with a bag in 3D are 44% more likely to add it to their cart and 27% more likely to place an order. The gap however compares visitors who chose to interact with visitors who did not. Someone who has already decided to buy examines the product more closely, with or without 3D. These figures describe a correlation and come from a platform that sells the feature.
The most robust measurement is academic. A study published in 2022 in the Journal of Marketing (opens in a new tab) analysed data from an international cosmetics retailer whose mobile app offered augmented reality try-on. Its authors summarise the results (opens in a new tab) in two parts. The effect on sales is positive and "the overall impact appears to be small". It is stronger for less popular brands, for niche products and for more expensive products.
The study covers augmented reality in an app rather than a WebGPU website. The mechanism it describes does not depend on the technology. Visualisation reduces the buyer's uncertainty and weighs most where that uncertainty is high. An established brand selling a familiar product gains little from it. A lesser-known manufacturer whose product is expensive, configurable or hard to picture from a photo is in the case where the measured effect is clearest.
The WebGPU limits to plan for before going to production
The graphics device can disappear mid-session. Figma observed it on Windows during its rollout. The WebGPU device was sometimes lost without the application being able to request a new one, which no test at load time detected. The team built a dynamic fallback to WebGL, triggered during use. The interface provides for this case with the device.lost promise, documented on MDN (opens in a new tab).
device.lost.then((info) => {
if (info.reason === "destroyed") return;
console.warn(`WebGPU device lost: ${info.message}`);
startWebGLFallback();
});Reacting to the loss of the graphics device
The weight of the code adds to that of the page. The main build of Three.js weighs 185 KB once compressed, according to Bundlephobia (opens in a new tab), before the first 3D model and the first texture. Loading the scene after the content, when the visitor approaches the relevant area, keeps the page's text and images out of that wait. The trade-off between visual richness and performance metrics is detailed in the article on the paradox of award-winning sites (opens in a new tab).
A canvas is invisible to assistive technologies. Nothing drawn in it is read by a screen reader and MDN asks for alternative content (opens in a new tab) between the tags. On a configurator, the options remain real HTML buttons placed next to the scene. The price, the reference and the specifications remain text. The 3D scene then enriches a page that works without it, following the logic of progressive enhancement (opens in a new tab).
Not all tools are at the same stage. Three.js, Babylon.js and PlayCanvas offer a WebGPU engine. Unity still describes its WebGPU export as experimental (opens in a new tab) in its documentation and keeps WebGL 2 as the default.
When to choose WebGPU for a website project
- On a new 3D project with Three.js, start with
WebGPURenderer. The fallback to WebGL 2 covers the missing browsers with no extra code - On an existing WebGL scene that works, there is no rush. Figma's experience shows a gain on only part of the devices
- On a scene limited by its number of objects, WebGPU reduces the central processor's work on every frame
- On a project that needs a simulation, particles in large numbers or local AI, WebGPU brings what WebGL cannot do
- On a Unity project targeting the web, stay on WebGL 2 as long as the WebGPU export is described as experimental
- Raw WebGPU without a library concerns teams that write their own rendering engine
What WebGPU takes out of the 3D debate
Until 2025, WebGPU ran only in Chrome and Edge, which confined it to demos. Since September 2025 it has run on the iPhone. A single rendering engine covers the browsers that know it and those that do not. The technical cost of a 3D scene on a brand, manufacturer or retailer website has fallen accordingly.
The remaining question concerns the product. The available data points to a real effect, concentrated where the buyer hesitates for lack of a way to picture what is being bought. An expensive, configurable or lesser-known product falls into that case. A product that a few photos are enough to describe gains less from it.