1. The 2026 WebGPU Map — All Three Browsers GA

For more than a decade, browser graphics lived on WebGL 1.0 (2011) and WebGL 2.0 (2017). In 2026 the **next-generation standard** has finally arrived. Chrome 113 (May 2023), Safari 18 (Sept 2024) and Firefox 141 (Aug 2025) — every evergreen browser supports WebGPU as stable.

WebGPU is not "just a faster WebGL."

- **A modern GPU API abstraction** — a thin layer over Vulkan / Metal / DirectX 12

- **Compute shaders as first-class citizens** — general-purpose GPU compute in the browser

- **WGSL** — a brand new shading language to replace GLSL (Rust-flavoured syntax, co-designed by Apple / Google / Mozilla)

- **Explicit pipelines** — fewer drawcall overheads, friendlier to multi-threading

- **Bind groups and buffer management** — current graphics-API best practice as-is

As of May 2026 the answer to "should we use WebGPU?" is simple. **For a new project, start with WebGPU and keep WebGL as a fallback.** This article walks through the spec, browsers, WGSL, compilers, libraries and ML applications, one layer at a time.

> Not a single line of code in this article uses a polyfill. Everything targets the stable features of evergreen browsers as of May 2026.

2. The WebGPU Spec — From Working Draft to Candidate Recommendation

Where the spec lives

WebGPU is driven by W3C's **GPU for the Web Working Group**. Apple (WebKit), Google (Chrome / Dawn), Mozilla (Firefox / wgpu), Microsoft and Intel are joint editors.

- **Working Draft** — 2021 to 2025, active changes

- **Candidate Recommendation** — entered in 2026, signal of stabilisation

- **Recommendation** — expected within the next year or two

Hitting CR means **WPT (Web Platform Tests) coverage is sufficient and implementation interoperability has been demonstrated**. It is no longer a "works on one browser only" thing.

Two axes of the spec

1. **WebGPU API** — the JavaScript interface for talking to the GPU (device / queue / pipeline / binding)

2. **WGSL** — the shading language spec for writing vertex / fragment / compute shaders

The two specs are managed as separate documents but evolve together. The stable feature set at CR includes:

- Render pipeline / compute pipeline

- Bind group / bind group layout

- Buffer / texture / sampler

- Storage buffer / storage texture

- Indirect draw / indirect dispatch

- Timestamp query / occlusion query

- WGSL 1.0 core (struct, function, control flow, atomic ops)

Proposals queuing up after CR

- **Subgroups** — SIMD-group (warp) communication, compute performance accelerator

- **Storage texture extensions** — read-write storage textures

- **Mesh shaders** — redesign of the vertex pipeline (Nanite-style)

- **Ray-tracing** — exposing hardware RT (abstraction over Vulkan RT / DXR / Metal RT)

- **bfloat16** — 16-bit floats for ML inference

CR is not the end, it is the beginning. Expect these extensions to land in 2026 and 2027.

3. Browser Support — Chrome 113 / Safari 18 / Firefox 141

Chrome — May 2023 GA

Chrome 113 was the first GA. Available on macOS / Windows / ChromeOS / Android. Linux stayed behind a flag for a while and gradually flipped on through 2024. Chrome's backend is Google's own **Dawn** (C++).

- Render backends

- Windows → Direct3D 12 (D3D11 fallback)

- macOS / iOS → Metal

- Linux / Android → Vulkan

- Compiler → **Tint** (WGSL → SPIR-V / MSL / HLSL)

Safari — September 2024 GA

Safari 18 and iOS 18 brought GA. WebKit's backend is its own implementation. macOS / iOS / iPadOS / visionOS all run on Metal. The spatial-computing graphics layer of visionOS is also drivable through WebGPU.

- WebGPU in iOS Safari is huge for games and ML inference that want to use mobile GPUs

- WebKit was deeply involved in the spec process, with a heavy emphasis on JS-engine WebGPU security

Firefox — August 2025 GA

Firefox 141 was the final GA. The backend is **wgpu** (Mozilla / gfx-rs, Rust). The compiler is **naga** (WGSL / SPIR-V / GLSL / MSL / HLSL cross-compiler, also Rust).

- The wgpu + Vulkan combo on Linux desktop is rock solid

- Firefox prioritised desktop first; mobile is staged

Feature detection

if (!navigator.gpu) {

throw new Error('WebGPU not supported by this browser')

}

const adapter = await navigator.gpu.requestAdapter()

if (!adapter) {

throw new Error('No GPU adapter available')

}

const device = await adapter.requestDevice({

requiredFeatures: ['timestamp-query'],

requiredLimits: {

maxStorageBufferBindingSize: 1024 * 1024 * 1024,

},

})

> A missing adapter typically means (a) the browser does not support WebGPU, (b) the GPU driver is too old or (c) the user blocked it via policy. All three are common in the wild, so always wire up a fallback path.

Coexistence with WebGL

WebGPU does **not** completely replace WebGL. Even in 2026 WebGL 1 and 2 are needed for (1) legacy device support, (2) low-power mobile devices and (3) WebView / WKWebView embedding. In practice you keep both backends.

4. WGSL — The WebGPU Shading Language

Why not GLSL?

GLSL syntax dates back to the OpenGL era (2004). It does not match the explicitness, safety and tooling friendliness expected from modern graphics APIs. WGSL is a **new shading language with Rust-flavoured syntax**, co-designed by Apple, Google and Mozilla.

- Explicit types and annotations

- Function declarations in Rust / Swift style

- A clearly defined memory model (storage, uniform, workgroup, private)

- Security-friendly (out-of-bounds is defined, undefined behaviour is minimised)

Hello triangle in WGSL

struct VsIn {

@location(0) position: vec3<f32>,

@location(1) color: vec3<f32>,

}

struct VsOut {

@builtin(position) clip_position: vec4<f32>,

@location(0) color: vec3<f32>,

}

@vertex

fn vs_main(input: VsIn) -> VsOut {

var out: VsOut;

out.clip_position = vec4<f32>(input.position, 1.0);

out.color = input.color;

return out;

}

@fragment

fn fs_main(input: VsOut) -> @location(0) vec4<f32> {

return vec4<f32>(input.color, 1.0);

}

Highlights compared to GLSL.

- Intent is expressed through **attributes** like `@location`, `@builtin`, `@vertex`, `@fragment`

- Types are explicit (vec3 of f32 etc.)

- `let` versus `var` distinction (Rust influence)

Compute shaders — GPGPU as a first-class citizen

@group(0) @binding(0) var<storage, read> input: array<f32>;

@group(0) @binding(1) var<storage, read_write> output: array<f32>;

@compute @workgroup_size(64)

fn cs_main(@builtin(global_invocation_id) gid: vec3<u32>) {

let i = gid.x;

if (i >= arrayLength(&input)) {

return;

}

output[i] = input[i] * 2.0;

}

This 16-line compute shader unlocks **what WebGL never delivered**: general-purpose GPU compute as a web standard. ML inference, particle simulation, image processing, sorting and prefix sums — they all start here.

Memory address spaces

| Address space | Purpose | Example |

| --- | --- | --- |

| `storage` | Large buffers (read / read_write) | Vertex / particle data |

| `uniform` | Small constants (read only) | Camera matrix |

| `workgroup` | Shared memory within a workgroup | Scratch for reductions |

| `private` | Function-local | Mostly compiler-managed |

The explicit address spaces expose the GPU memory hierarchy directly. Much more honest than the GLSL `uniform` keyword.

5. wgpu (Rust) — Mozilla / gfx-rs's Portable WebGPU

What is wgpu?

**wgpu** is a **WebGPU implementation written in Rust** by Mozilla and the gfx-rs community. It plays two roles.

1. **Firefox's backend** — Firefox WebGPU is powered by wgpu

2. **A native library** — letting Rust (or C / C++ / Python) consume the WebGPU API as a portable layer

The second role is the real story: it means you can use **the WebGPU spec on native applications** as well.

wgpu's backends

wgpu (Rust crate)

├─ Vulkan (Linux / Android / Windows / macOS via MoltenVK)

├─ Metal (macOS / iOS)

├─ DirectX 12 (Windows)

├─ OpenGL ES 3 (legacy device fallback)

└─ WebGPU (browser wasm builds)

The same code compiles for Linux native, Mac native, Windows native and browser wasm — five targets from one source tree.

A small wgpu example (Rust)

use wgpu::util::DeviceExt;

async fn run() {

let instance = wgpu::Instance::default();

let adapter = instance

.request_adapter(&wgpu::RequestAdapterOptions::default())

.await

.unwrap();

let (device, queue) = adapter

.request_device(&wgpu::DeviceDescriptor::default(), None)

.await

.unwrap();

let shader = device.create_shader_module(wgpu::ShaderModuleDescriptor {

label: Some("triangle.wgsl"),

source: wgpu::ShaderSource::Wgsl(include_str!("triangle.wgsl").into()),

});

// ... pipeline / bind groups / draw

}

The Rust game engine **Bevy**, the GUI framework **iced** and the embedded graphics library **Lyon** are all built on wgpu. The WebGPU spec has effectively become the baseline for Rust native apps.

Who uses wgpu?

- **Mozilla / Firefox** — browser backend

- **Deno** — exposes WebGPU on the server side

- **Bevy** — default renderer of the Rust game engine

- **gfx-rs community** — soil of the Rust graphics ecosystem

6. naga + Tint — Two WGSL Compilers in the Family

naga (Rust, gfx-rs)

**naga** is the shader translation toolkit that grew up alongside wgpu.

- WGSL parser and writer

- Cross-compiles between SPIR-V, WGSL, GLSL, MSL and HLSL

- Both a Rust crate and a CLI

Convert WGSL to Metal Shading Language

cargo install naga-cli

naga shader.wgsl shader.metal

Convert WGSL to SPIR-V

naga shader.wgsl shader.spv

Almost every shader tool in the Rust ecosystem sits on top of naga.

Tint (C++, Google Dawn)

**Tint** is the C++ compiler Google built for Dawn (Chrome's WebGPU implementation).

- WGSL → SPIR-V (Vulkan backend)

- WGSL → MSL (Metal backend)

- WGSL → HLSL (D3D12 backend)

- WGSL validation, IR passes, optimisation

Tint lives inside Dawn rather than as a standalone CLI, so it usually runs from within the Chromium tree. It is close to the reference implementation of the WGSL spec.

Which compiler runs where?

| Environment | Compiler |

| --- | --- |

| Chrome (any OS) | Tint |

| Safari (Mac / iOS / visionOS) | WebKit's in-house compiler (WGSL → AIR / MSL) |

| Firefox (any OS) | naga |

| wgpu native | naga |

| Dawn native (C++ apps) | Tint |

The same WGSL code passes through three different compilers and translates to three different OS graphics APIs. That is why **spec conformance** matters more than ever.

WGSL validation

naga --validate shader.wgsl

Validating shaders at build time catches breakage before runtime. Wiring this into CI is becoming a popular pattern.

7. Three.js WebGPU Renderer (r163+, May 2024)

r163 — Three.js WebGPU graduates

The **Three.js r163** release in May 2024 made the WebGPU renderer official. It had been experimental since r137 (2022), but r163 marked it production ready.

const renderer = new WebGPURenderer({ antialias: true })

renderer.setSize(window.innerWidth, window.innerHeight)

document.body.appendChild(renderer.domElement)

const scene = new THREE.Scene()

const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000)

const geometry = new THREE.BoxGeometry()

const material = new THREE.MeshStandardMaterial({ color: 0x6699ff })

const cube = new THREE.Mesh(geometry, material)

scene.add(cube)

scene.add(new THREE.AmbientLight(0xffffff, 0.5))

scene.add(new THREE.DirectionalLight(0xffffff, 1))

camera.position.z = 5

renderer.setAnimationLoop(() => {

cube.rotation.x += 0.01

cube.rotation.y += 0.01

renderer.render(scene, camera)

})

The code is almost identical to the WebGL renderer.

TSL — Three.js Shading Language

A more interesting Three.js bet is **TSL** (Three Shading Language). Instead of writing WGSL or GLSL directly, you compose shaders from JavaScript functions.

const baseColor = uniform(color(0xff6633))

const wave = sin(mul(attribute('position').x, 2.0).add(time))

const finalColor = baseColor.mul(wave.add(1.0).mul(0.5))

material.colorNode = finalColor

TSL emits both WGSL and GLSL automatically. **One shader source targets both WebGPU and WebGL** — that is the point.

Three.js migration playbook

1. Swap the import from `WebGLRenderer` to `WebGPURenderer`

2. Confirm it works, then gradually migrate hand-written shader bits to TSL

3. Build out compute shaders (particles, GPGPU) as net-new features

Who uses it?

- **Vercel** — some marketing pages

- **Toss** — parts of their data-viz stack (WebGPU compute shaders)

- **Kakao Games** — some web prototypes

- **Three.js Journey** (Bruno Simon) — courses updated to use WebGPU / TSL

8. Babylon.js WebGPU (5.x, 6.x)

Babylon.js's bet on WebGPU

Microsoft-backed **Babylon.js** placed an early bet on WebGPU. The 5.0 release in 2021 introduced an experimental WebGPU engine, and 6.0 in 2023 stabilised it. Its strength is going hand-in-hand with full game-engine features.

const canvas = document.getElementById('renderCanvas')

const engine = await WebGPUEngine.IsSupportedAsync

? await new WebGPUEngine(canvas).initAsync().then((e) => e ?? null) || new Engine(canvas, true)

: new Engine(canvas, true)

const scene = new Scene(engine)

const camera = new FreeCamera('cam', new Vector3(0, 5, -10), scene)

camera.setTarget(Vector3.Zero())

camera.attachControl(canvas, true)

new HemisphericLight('light', new Vector3(0, 1, 0), scene)

const box = MeshBuilder.CreateBox('box', { size: 2 }, scene)

engine.runRenderLoop(() => scene.render())

`WebGPUEngine.IsSupportedAsync` detects support before falling back.

Babylon.js strengths

- **PBR + IBL** — cinematic shading

- **Node Material Editor** — node-based shader GUI

- **Physics** — Cannon / Havok integration

- **GUI** — game UI and demo widgets

- **glTF import** — standard model format

It is strong for games, simulations and digital twins. If Three.js is a "graphics building block", Babylon.js is closer to an "engine".

Babylon.js + WebGPU compute

const cs = new ComputeShader('add', engine, {

computeSource: `

@group(0) @binding(0) var<storage, read_write> data: array<f32>;

@compute @workgroup_size(64)

fn main(@builtin(global_invocation_id) gid: vec3<u32>) {

data[gid.x] = data[gid.x] * 2.0;

}

`,

})

const buffer = new StorageBuffer(engine, 1024 * 4)

cs.setStorageBuffer('data', buffer)

cs.dispatch(16, 1, 1)

You can run GPGPU compute inline with the game engine.

9. Filament Web / regl / gpu.js / PlayCanvas

Filament Web — Google's PBR engine

Google's **Filament** (C++) has set the bar for mobile PBR since Android's sceneform days. It ships a WebAssembly + WebGPU/WebGL build as Filament Web.

- Cinematic PBR + IBL (image-based lighting)

- Careful tone mapping and white balance

- Standards-compliant glTF import

The WebGPU backend has been ramping up through 2025. It brings the seriousness of a C++ graphics engine straight into the browser.

regl — functional WebGL / WebGPU

**regl** (by Mikola Lysenko) wraps imperative WebGL in a functional API. Small, fast and easy to learn.

const draw = regl({

vert: `

precision mediump float;

attribute vec2 position;

void main() {

gl_Position = vec4(position, 0, 1);

}

`,

frag: `

precision mediump float;

uniform vec4 color;

void main() { gl_FragColor = color; }

`,

attributes: { position: [[-1, 0], [0, -1], [1, 1]] },

uniforms: { color: [1, 0, 0, 1] },

count: 3,

})

regl.frame(() => draw())

WebGPU backends (regl-gpu, etc.) are emerging. It is a popular pick for learning graphics and for data visualisation.

gpu.js — JavaScript to GPU compute

**gpu.js** turns JavaScript functions into GPU shaders to run as GPGPU. Historically backed by WebGL, with a WebGPU backend now landing.

const gpu = new GPU()

const multiplyMatrix = gpu

.createKernel(function (a, b) {

let sum = 0

for (let i = 0; i < 512; i++) {

sum += a[this.thread.y][i] * b[i][this.thread.x]

}

return sum

})

.setOutput([512, 512])

const c = multiplyMatrix(matA, matB)

Great for fast prototyping of ML or image processing kernels.

PlayCanvas — browser game engine

**PlayCanvas** is a UK-born browser game engine. ECS-based with a hosted editor, and it officially supports the WebGPU backend. It shows up a lot in 3D interactive ads and marketing experiences.

- ECS component model

- Cloud editor (edit scenes in the browser)

- glTF / physics / sound / animation

- Dual backend: WebGL2 + WebGPU

Disney and BMW are among the brands that ship 3D ads on PlayCanvas.

10. WebLLM (MLC LLM) — In-browser LLM Inference

What is WebLLM?

The CMU / MLC team's **MLC LLM** project built **WebLLM**, a library that runs LLMs (Llama, Mistral, Phi, etc.) **inside the browser** through WebGPU. No server, no data leaving the device.

const engine = await webllm.CreateMLCEngine('Llama-3-8B-Instruct-q4f32_1-MLC')

const reply = await engine.chat.completions.create({

messages: [

{ role: 'system', content: 'You are a helpful assistant.' },

{ role: 'user', content: 'Tell me briefly about the future of WebGPU.' },

],

})

console.log(reply.choices[0].message.content)

The API mirrors OpenAI's chat completions (`chat.completions.create`).

Tech stack

- **The MLC LLM compiler** — compiles PyTorch models into WebGPU shaders via TVM

- **WGSL compute shaders** — matmul / attention / RMSNorm and the rest of the core ops

- **FP16 / INT4 quantisation** — keeps model size browser-friendly

Performance (2026 baseline)

- 30 to 60 tokens per second for Llama-3 8B (q4 quantised) on an M3 MacBook Pro

- 20 to 30 tokens per second for Phi-3.5-mini (3.8B) on an M2 iPad

- 80 to 120 tokens per second on desktop RTX 4070 + Chrome WebGPU

About 50 to 70 percent of server inference throughput. But the **zero inference cost** is overwhelming.

Who uses it?

- **Chatbot demos** — try-out experiences for local LLMs

- **Privacy-sensitive services** — healthcare, legal, schools (no data leaves the browser)

- **Offline PWAs** — works in airplane mode

- **On-device agents** — browser extensions

11. Transformers.js (Xenova) — WebGPU Accelerated

What is Transformers.js?

**Transformers.js** (authored by Xenova) ports Hugging Face's **Transformers** to the browser, running nearly any small model (BERT, DistilBERT, Whisper, CLIP, ViT, SAM, etc.) on-device. From 2024 onwards the **WebGPU backend is official**.

// Force the WebGPU backend

const pipe = await pipeline('sentiment-analysis', 'Xenova/distilbert-base-uncased-finetuned-sst-2-english', {

device: 'webgpu',

})

const result = await pipe('I love WebGPU in 2026.')

console.log(result)

// [{ label: 'POSITIVE', score: 0.9998 }]

Supported tasks

- **NLP** — sentiment analysis, fill-mask, summarisation, translation, question answering

- **Speech** — Whisper (ASR), VAD

- **Vision** — CLIP, SAM, DINO, ViT, OWL-ViT

- **Multimodal** — LLaVA-Phi, Florence-2

Almost every smaller Hugging Face model converts to ONNX and runs through WebGPU.

Use cases

- **Semantic search in search UI** — sentence-transformers running in the browser

- **Recording to captions** — Whisper-tiny / base

- **Image classification / embeddings** — CLIP in the browser

Performance

Large models (70B class) are still out of reach, but small models (under 500M) fly. DistilBERT-base inference runs in 5 to 10 ms on a desktop WebGPU device.

12. React Three Fiber WebGPU / ONNX Runtime WebGPU

React Three Fiber (R3F) WebGPU

**React Three Fiber** wraps Three.js in React components. From 2025 it officially supports the WebGPU renderer.

export default function Scene() {

return (

gl={(canvas) => {

const renderer = new WebGPURenderer({ canvas, antialias: true })

return renderer

}}

>

)

}

A declarative React API on top of WebGPU acceleration. Ideal for 3D interactives in marketing and product pages.

ONNX Runtime Web — WebGPU backend

Microsoft's **ONNX Runtime Web** runs ONNX models in the browser. You can pick a backend among WebGL, WASM and **WebGPU**.

const session = await ort.InferenceSession.create('./model.onnx', {

executionProviders: ['webgpu'],

})

const feeds = { input: new ort.Tensor('float32', new Float32Array(224 * 224 * 3), [1, 3, 224, 224]) }

const results = await session.run(feeds)

console.log(results.output.data)

Models trained in PyTorch or TensorFlow get exported to ONNX and inferred in the browser through WebGPU. For enterprise workloads it is the safest default.

Which library for which scenario?

| Scenario | Library |

| --- | --- |

| LLM chat demo | WebLLM |

| Small BERT / Whisper models | Transformers.js |

| Internal ONNX models | ONNX Runtime Web (WebGPU) |

| 3D marketing | Three.js / R3F WebGPU |

| Games / simulations | Babylon.js / PlayCanvas |

| Rust native + browser | wgpu |

13. Web Stable Diffusion — SD in the Browser

Web Stable Diffusion

The CMU / MLC team also produced **Web Stable Diffusion**, which runs Stable Diffusion 1.5 / 2.1 **inside the browser** through WebGPU. Text-to-image with no server calls.

- Model size around 2.1 GB (quantised)

- Cached after the initial download (IndexedDB)

- About 20 to 40 seconds per image on an M2 MacBook

- About 8 to 15 seconds on RTX 4070 with Chrome WebGPU

How it works

1. Compile UNet / VAE / text encoder via ONNX or MLC

2. Cache the weights in IndexedDB

3. Run the diffusion loop: text to CLIP to UNet to VAE decode

4. Draw the final image to a canvas

The entire pipeline stays in the browser. Server bills disappear.

Applications

- **Personal image generators** — no sign-up, no credit card

- **Educational demos** — diffusion model demonstrations

- **Creative tools** — offline-capable PWAs

Limits

- The initial 2 to 3 GB download is a real barrier

- Big SDXL models (7 GB+) are not yet practical

- Mobile lacks NPU support, so desktop is still the focus

Solving these is the agenda for the next round of WebGPU extensions (bfloat16, mesh shaders, ray-tracing) in 2026 and 2027.

14. Compute Shaders + Storage Texture + Subgroups + the mesh shaders future

What compute shaders changed

WebGPU's real revolution is not graphics, it is **GPGPU**.

- **Particle systems** — moving from CPU to GPU (millions of particles)

- **Physics simulation** — position-based dynamics, MLS-MPM

- **Image / video processing** — real-time filters, OpenCV replacement

- **ML inference** — matmul, attention, conv2D

- **Data visualisation** — millions-of-points clustering and KDE

Toss's data visualisation team is the case study most often cited in Korea. Interactive charts with hundreds of thousands of points running at 60 fps.

Storage textures

@group(0) @binding(0) var<storage, read_write> output: texture_storage_2d<rgba8unorm, write>;

@compute @workgroup_size(8, 8)

fn cs_main(@builtin(global_invocation_id) gid: vec3<u32>) {

let coord = vec2<i32>(i32(gid.x), i32(gid.y));

let color = vec4<f32>(0.5, 0.7, 1.0, 1.0);

textureStore(output, coord, color);

}

Read-only and write-only storage textures today. **Read-write storage textures** are slated to land later in 2026 as an extension.

Subgroups (warp messaging)

enable subgroups;

@compute @workgroup_size(64)

fn cs_main(@builtin(subgroup_invocation_id) sid: u32) {

let value = some_input[sid];

let sum = subgroupAdd(value);

// 32 to 64 times faster reductions inside a warp

}

The web analogue of CUDA warp shuffle and Metal SIMD-group messaging. The key to optimising sort, scan, matmul and attention.

Mesh shaders

Instead of the classic "vertex buffer to index buffer to vertex shader to rasteriser" pipeline, mesh shaders **emit small meshes (meshlets) directly**. They open the door to Unreal Engine Nanite-style virtualised micropolygons.

W3C proposal stage in 2026. Stabilisation expected around 2027 to 2028.

Ray-tracing

A browser abstraction over DXR / Vulkan RT / Metal RT. Global illumination, reflections and refractions straight from a shader. Still in the proposal phase, but a huge unlock for games and visualisation once it ships.

15. Korea / Japan — Toss, Kakao Games, pixiv, CyberAgent

Korea

Toss

Since 2024 the Toss data visualisation team has been using WebGPU compute shaders. Interactive charts over hundreds of thousands of transactions and clustering algorithms now run on the GPU inside the browser. A talk at the SLASH conference sparked broader interest across the Korean developer community.

- Large-scale data visualisation (hundreds of thousands of points)

- Real-time filtering and zoom

- WebGL fallback retained

Kakao Games

Experimenting with PlayCanvas + WebGPU for some web game prototypes. Mobile browser compatibility (iOS Safari 18, Android Chrome) lowers the bar for game distribution.

NAVER D2 / CLOVA

NAVER LABS and D2 keep publishing WebGPU content. The CLOVA team has shipped ML inference demos based on Transformers.js and ONNX Runtime Web.

Japan

pixiv

The pixiv creator platform is rolling out WebGPU in selected interactive components (stickers and effects). Real-time effects that JavaScript could not handle now run on WebGPU compute.

CyberAgent

Heavy adoption in ads and games. 3D ads, simulations, live-broadcast effects — all migrating to WebGPU. Some of AbemaTV's interactive content is part of this wave.

LINE / Yahoo Japan

Piloting WebGPU compute shaders for large-scale data visualisation. The motivation is similar to Toss.

Globally

- **Vercel** — 3D on marketing pages

- **Figma** — evaluating parts of the render pipeline

- **Adobe** — GPU acceleration in pieces of Photoshop Web

- **Google Earth Web** — testing a WebGPU backend

- **Unreal Engine Pixel Streaming** — exploring WebGPU clients

16. Who Should Learn WebGPU? Games / Data Viz / Browser ML

Recommendations by scenario

Games and interactive 3D

- Three.js (lower bar, big community) or Babylon.js (engine-grade features)

- Author shaders in TSL or write WGSL directly

- Keep a WebGL2 fallback for mobile compatibility

Data visualisation (hundreds of thousands to millions of points)

- regl, or Three.js BufferGeometry + compute shaders

- The Toss pattern: clustering / KDE / heatmaps moved to the GPU

- Pairs well with Observable / D3

Browser ML inference

- Small models (BERT, Whisper-tiny, CLIP) → Transformers.js

- Internal ONNX models → ONNX Runtime Web

- LLM chat demo → WebLLM

- SD and image generation → Web Stable Diffusion

Native + web integration

- Build the core on top of wgpu in Rust

- Build the same code as a wasm bundle for the browser

- Lean on Rust graphics ecosystems like Bevy and iced

Learning path

1. **WGSL basics** — start with small `@vertex`, `@fragment`, `@compute` programs

2. **Calling WebGPU directly** — touch pipelines, bind groups and buffers by hand

3. **Three.js / Babylon.js** — fast wins with high-level libraries

4. **Compute shaders** — GPGPU patterns (reduce, scan, matmul)

5. **ML inference integration** — apply Transformers.js or ONNX Runtime Web

Common pitfalls

- **Browsers are not identical** — test on Chrome, Safari and Firefox

- **WGSL compiler differences** — Tint, WebKit and naga occasionally diverge

- **WebGL fallback is mandatory** — for legacy devices and WebView

- **Initial load cost** — measure shader compilation and weight download

- **Memory limits** — mobile GPUs have small memory (2 to 4 GB), so manage model sizes

Conclusion — the GPU web of 2026

WebGPU is no longer "coming soon". **It is already here.** Chrome, Safari and Firefox are all GA. The spec is at CR. The library ecosystem is mature. The 2026 answer is simple.

> **For new graphics or GPGPU projects, start with WebGPU and keep WebGL as a safety net. Browser ML at any scale is no longer feasible without WebGPU.**

References

- W3C — [WebGPU Specification](https://www.w3.org/TR/webgpu/)

- W3C — [WGSL Specification](https://www.w3.org/TR/WGSL/)

- W3C — [GPU for the Web Working Group](https://www.w3.org/community/gpu/)

- MDN Web Docs — [WebGPU API](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)

- Chrome Developers — [Get started with WebGPU](https://developer.chrome.com/docs/web-platform/webgpu/)

- WebKit blog — [WebGPU in Safari](https://webkit.org/blog/15788/webgpu-in-safari/)

- Mozilla Hacks — [WebGPU in Firefox](https://hacks.mozilla.org/category/webgpu/)

- wgpu — [wgpu.rs](https://wgpu.rs/)

- gfx-rs — [github.com/gfx-rs/wgpu](https://github.com/gfx-rs/wgpu)

- naga — [github.com/gfx-rs/naga](https://github.com/gfx-rs/naga)

- Google Dawn — [dawn.googlesource.com](https://dawn.googlesource.com/dawn)

- Three.js — [threejs.org](https://threejs.org/)

- Three.js WebGPU examples — [threejs.org/examples/?q=webgpu](https://threejs.org/examples/?q=webgpu)

- Babylon.js — [babylonjs.com](https://www.babylonjs.com/)

- Babylon.js WebGPU docs — [doc.babylonjs.com/setup/support/webGPU](https://doc.babylonjs.com/setup/support/webGPU)

- Filament — [google.github.io/filament](https://google.github.io/filament/)

- regl — [regl.party](https://regl.party/)

- gpu.js — [gpu.rocks](https://gpu.rocks/)

- PlayCanvas — [playcanvas.com](https://playcanvas.com/)

- React Three Fiber — [r3f.docs.pmnd.rs](https://r3f.docs.pmnd.rs/)

- WebLLM (MLC LLM) — [webllm.mlc.ai](https://webllm.mlc.ai/)

- Transformers.js (Xenova) — [huggingface.co/docs/transformers.js](https://huggingface.co/docs/transformers.js)

- ONNX Runtime Web — [onnxruntime.ai/docs/tutorials/web](https://onnxruntime.ai/docs/tutorials/web/)

- Web Stable Diffusion — [mlc.ai/web-stable-diffusion](https://mlc.ai/web-stable-diffusion/)

- Bevy game engine — [bevyengine.org](https://bevyengine.org/)

- NAVER D2 — [d2.naver.com](https://d2.naver.com/)

- Toss SLASH conference — [toss.tech/slash](https://toss.tech/slash)

- pixiv inside — [inside.pixiv.blog](https://inside.pixiv.blog/)

- CyberAgent developer blog — [developers.cyberagent.co.jp](https://developers.cyberagent.co.jp/)

- Can I Use — WebGPU — [caniuse.com/webgpu](https://caniuse.com/webgpu)

- WebGPU Samples — [webgpu.github.io/webgpu-samples](https://webgpu.github.io/webgpu-samples/)