WebGPU vs WebGL in 2025: what changed
WebGPU is the next-generation graphics API for the browser, designed to expose Vulkan, Metal, and D3D12 directly. After several years behind a flag, the critical milestone was crossed in 2025: Chrome and Edge (Chromium 113+) shipped it stable to all users, Safari 26 (macOS 26, iOS 26) enables it by default, and Firefox removed the main technical barrier by dropping the compilation option that blocked delivery. As of August 2025, over 85% of desktop users are compatible according to StatCounter.
The difference from WebGL isn't just rendering. WebGL is a fifteen-year-old API mapped onto OpenGL ES 2.0/3.0: global state, synchronous, designed to draw triangles. WebGPU brings a modern model: explicit render passes, precompiled pipelines, immutable objects, and above all native **compute shaders**. That last block is what changes the game for B2B apps.
In practice, WebGL forced all GPU computation into contortions: encode data into textures, run a fragment shader, read the result back. With WebGPU, a compute shader takes a `storage buffer` as input, transforms it in parallel, and writes it into another buffer. The GPU becomes a generic coprocessor usable from JavaScript. For the first time, workloads previously reserved for native (CAD rendering, video processing, simulation, ML inference) become legitimate in the browser.
B2B use cases that justify the investment
WebGPU has a real cost: specialised skills (WGSL, pipelines, GPU memory), fallback complexity, harder debugging. You don't deploy it for a visual effect. You deploy it when the product draws direct value from local GPU compute. Four families of B2B cases justify it in 2025.
The first: **video and image processing in the browser**, on the Adobe Express or Canva model. Colour grading filters, keying, denoising, preview encoding, motion tracking: everything that used to require server transcoding becomes executable locally. On an Intel Arc A380 desktop, a 4K gaussian blur compute shader runs at 16 ms/frame versus 240 ms in Canvas2D — a 15x factor that transforms the UX.
The second: **3D product configurators and CAD visualisation**. Custom furniture, fitted kitchens, foldable packaging, industrial installations. Here it's the rendering (not the compute) that speaks: full PBR, real-time shadows, tens of millions of polygons. three.js r170 ships a mature `WebGPURenderer` that exploits these capabilities, and Babylon.js 7 made WebGPU a first-class citizen.
The third: **scientific visualisation and high-density data-vox**. Medical imaging (DICOM volumes), CFD simulation, 3D mapping of IoT networks, financial flows plotted over millions of points. The compute shader sorts, aggregates, and filters on the GPU; the renderer displays the result. No more JS bottlenecks beyond 100k points.
The fourth, and probably the most strategic for 2025-2026: **local ML inference**, covered in detail below.
The compute shader: the real breakthrough
A compute shader runs thousands of threads in parallel on the GPU. Granularity is explicit: workgroups of 64 to 256 threads, x/y/z dimensions, synchronisation barriers. It's the right model for any massively parallel algorithm: matrix products, sorting, reduction, N-body simulation, image processing, convolutions.
On an internal benchmark (reduction of a 16M float32 array, sum + min + max): a WebGPU compute shader on an RTX 3060 executes in 1.1 ms, a typed-array JavaScript loop takes 78 ms, a Web Worker 81 ms. A 70x factor. For a bitonic sort over 1M integers, we go from 420 ms (JS) to 6 ms (GPU). These numbers change an app's architecture: what used to be a server job becomes an instant local computation.
Concretely, the usage pattern is verbose but stable. You declare a pipeline with a WGSL module, allocate a `STORAGE` `GPUBuffer` with `mappedAtCreation`, write the data via an `ArrayBuffer`, encode a `dispatch(x, y, z)`, submit, copy to a mappable buffer, and read back. The whole machine runs in 80 lines of TypeScript. It's more direct than the WebGL equivalent and incomparably faster.
On-device AI via WebGPU: transformers.js, web-llm, ONNX
The most visible case in 2025 is running small language models directly in the browser. Three runtimes coexist: `transformers.js` (Hugging Face, WASM + WebGPU backend), `@mlc-ai/web-llm` (MLC, pure WebGPU optimised), and ONNX Runtime Web (Microsoft, WebGPU backend since 1.17). All leverage compute shaders for the transformer's matmul layer.
The gain is twofold. **Latency**: no network round trip, first token in 200-500 ms on an average laptop. **Privacy**: no data leaves the device — a decisive argument for legal, HR, health, and finance use cases. On an Intel Ultra 7 155H with 32 GB, Llama 3.2 1B runs at 38 tok/s in WebGPU, 3B at 14 tok/s. Gemma 2B hits 22 tok/s, Phi-3.5 mini (3.8B) 11 tok/s. Below that top tier, we stick to q4f16-quantised models — quality remains usable for classification, summarisation, and RAG over short contexts.
What does **not** run locally: 7B+ models (Llama 3.1 8B, Mistral 7B) except on high-end GPUs (RTX 4070+, 12 GB VRAM+), long contexts (> 8k tokens), and any multi-user streaming generation. The pragmatic rule: on-device for assistance, pre-classification, reranking, and short-document summarisation. Server for heavy, multi-tenant, or quality-guaranteed workloads.
Decision framework: when WebGPU, when to stay on WebGL/CPU
We apply a simple framework upstream of any WebGPU project. Three cumulative conditions must hold: (1) the GPU need delivers identified product value (latency, privacy, server savings); (2) the team accepts the maintenance debt (WGSL skills, debugging, testing); (3) the hardware target holds up at the p75 percentile of real users. If any one is missing, we stay on WebGL or CPU.
The clearest signal is migration away from a paid server step. If a product page triggers 50 ms of server compute to generate a render, a 5 ms local compute shader removes that cost and the network latency. If a cloud LLM call costs €0.005 per request and the case fits in a local 3B model, the savings pay for the model's bandwidth cost (1 to 2 GB, cached after the first visit via the Cache API). On a B2B SaaS at 10k sessions/day, the ROI materialises within weeks.
Progressive enhancement remains central. On browsers without WebGPU, we degrade gracefully: inference via the `transformers.js` WASM backend (2 to 4x slower but functional), rendering via WebGL2 (or canvas 2D for simple configurators), compute via a Web Worker (Typed Arrays + SharedArrayBuffer). The feature remains; only the speed changes. That is non-negotiable: locking out 15% of users on a critical feature is not acceptable.
Production pitfalls: mobile, battery, OS blocklists
Pitfall number one, and the most underestimated: **hardware diversity**. A mobile GPU (Adreno 740, Apple A17) is typically 8 to 12 times slower than a mid-range desktop GPU on a compute shader. A 1M-integer sort that takes 6 ms on an RTX 3060 takes 55 ms on an iPhone 15 Pro. For rendering, the gap is even wider on expensive effects (ray tracing, soft shadows). Measure on the real target; never extrapolate from desktop.
Pitfall number two: **laptop battery impact**. A continuously running compute shader drains a MacBook Air M2 in 2h instead of 12h. For a B2B business app used 6h/day, that's near-certain user rejection. Practical rules: throttle the frequency (30 fps where possible), pause when the tab is hidden (`document.visibilityState`), expose a user toggle, and watch `navigator.gpu`'s `adapter.info` to downscale resolution on battery (`navigator.getBattery()`).
Pitfall number three: **the OS/driver blocklist**. Chrome maintains a list of buggy drivers (Intel HD 4600 on old Windows, certain Mali GPUs on Android 12) where WebGPU is silently disabled. `navigator.gpu.requestAdapter()` then returns `null`, even though `navigator.gpu` exists. You must handle this case explicitly and switch to the fallback without a visible error. Same on Firefox Linux where some Mesa drivers are greylisted. The `if (!navigator.gpu)` test is not enough; always test the result of `requestAdapter()`.
Last point: telemetry. Report the WebGPU status in production (`adapter.requestAdapterInfo().vendor`, architecture, fallback used). Without real data, you don't know what share of the base actually benefits from the acceleration. On one of our desktop-first B2B clients (finance), we observe 91% WebGPU, 7% WebGL fallback, 2% WASM. On a mixed desktop/mobile client (logistics), it's 58% / 34% / 8%. These numbers drive the trade-offs.