Search “www spec” and you land on a W3C document that most engineers file mentally under “browser graphics.” That filing is where the mistake starts. The WebGPU specification defines a standards-backed API that exposes real GPU compute shaders — not a WebGL trick for visual effects, but a general-purpose parallel-compute surface that runs across NVIDIA, AMD, and Intel hardware through a single, vendor-neutral contract. The naive reading treats browser GPU access as a toy. The expert reading recognises that WebGPU sits in the same decision space as OpenCL and SYCL: it is a genuine portability option, with its own memory model and its own trade-offs. If your team assumes CUDA is the only path to GPU compute, you will never evaluate whether a spec-defined API could serve your deployment target — and you will accept lock-in you never quantified. What is the WebGPU specification, and who maintains it? WebGPU is a W3C specification developed by the GPU for the Web Community Group, with participation from browser vendors including Google, Mozilla, Apple, and Microsoft. It is not a single company’s runtime. It is a standard, and that distinction matters more than it first appears. A standard means the API contract — how you request a device, allocate buffers, bind resources, and dispatch a compute workload — is defined independently of any one GPU vendor. The specification pairs with WGSL (WebGPU Shading Language), the shader language you write compute kernels in. Browser implementations translate WGSL and the API calls down to the platform’s native driver: Vulkan on Linux and Android, Direct3D 12 on Windows, and Metal on Apple platforms. Google’s Dawn and Mozilla’s wgpu are the two reference-grade implementations, and wgpu in particular runs outside the browser as a native Rust library — which is why WebGPU is increasingly showing up as a portable compute backend well beyond web pages. The practical consequence is straightforward. When you write against the WebGPU spec, you are writing against a contract that three major GPU vendors have committed to implementing, rather than against one vendor’s proprietary toolkit. That is the whole value proposition, and it is also the source of every constraint the rest of this article describes. How does WebGPU expose compute shaders, and how does its model differ from CUDA? WebGPU exposes compute through compute pipelines. You author a kernel as a WGSL @compute entry point, declare a workgroup size, create a pipeline object, bind your buffers, and dispatch a grid of workgroups. Conceptually this maps cleanly onto what a CUDA engineer already knows: workgroups are analogous to CUDA thread blocks, invocations to threads, and workgroup-shared memory to CUDA shared memory. The divergence is in how explicit the resource model is. CUDA lets you allocate device memory and pass raw pointers into a kernel; unified virtual memory can hide the host-device boundary entirely. WebGPU refuses to hide it. Every buffer is created with an explicit usage flag set — STORAGE, COPY_SRC, UNIFORM — and every binding is described through a bind group layout that the pipeline validates against before dispatch. You cannot cast a pointer into arbitrary memory. You cannot read from a buffer you did not declare as readable. This explicitness is the portability trade-off, not an afterthought. A validated, capability-scoped binding model is what lets a browser hand your kernel to an untrusted web page and still guarantee memory safety across Vulkan, D3D12, and Metal. The cost is that porting a CUDA kernel is not a syntax translation — it is a restructuring around explicit buffer semantics. Teams that treat this as a mechanical port underestimate it; the memory model is the work. If you have hit this before with cross-vendor compute, the pattern will feel familiar from CUDA versus OpenCL when porting AI workloads, where the same “the kernel translated, the memory model didn’t” problem shows up. There is one more structural difference worth naming. WebGPU’s command model is asynchronous and buffered by design: you record commands into a command encoder, submit them to a queue, and read results back through an explicit mapping step. There is no implicit synchronous kernel launch. For workloads that expect fine-grained host-device ping-pong, this changes how you structure the algorithm, not just how you call the API. Where does WebGPU sit relative to CUDA, OpenCL, and SYCL? The honest framing is that these APIs occupy different points on a portability-versus-control curve. None dominates the others; the right choice depends on your deployment target and how much of the optimisation ceiling you are willing to trade for reach. Portable GPU compute API comparison Dimension WebGPU CUDA OpenCL SYCL Governance W3C standard NVIDIA proprietary Khronos standard Khronos standard Vendor reach NVIDIA, AMD, Intel, Apple NVIDIA only Broad, uneven Broad, via backends Runs in a browser Yes (native purpose) No No (WebCL retired) No Shader / kernel language WGSL CUDA C++ OpenCL C / C++ C++ single-source Memory model Explicit, validated buffers Pointers, optional UVM Explicit buffers Buffers / USM Access to vendor-specific features Limited by spec Full (Tensor Cores, etc.) Vendor extensions Backend-dependent Optimisation ceiling Portability-capped Highest on NVIDIA Mid, vendor-variable High, backend-variable (Evidence class: this is an observed-pattern synthesis of published API documentation and vendor-neutral standards, not a benchmark ranking. Treat the “optimisation ceiling” column as directional.) The row that decides most real cases is “runs in a browser.” WebGPU is the only entry that treats client-side, sandboxed GPU compute as a first-class target — which is precisely the gap left when WebCL never shipped in mainstream browsers, a history worth reading if you are evaluating what runs GPU compute in the browser today. If your deployment surface is a web page or an Electron-class app, WebGPU is effectively the standards-backed option, not one option among several. If your target is a controlled NVIDIA data-centre fleet and you need Tensor Core throughput at FP8 or FP16, CUDA’s ceiling is unmatched and portability is not your constraint. OpenCL and SYCL sit between these poles — OpenCL as the older cross-vendor workhorse, SYCL as the modern single-source C++ approach. Our broader position on choosing between them lives in the hardware-agnostic GPU compute discussion, and it applies here too: vendor-neutral does not mean performance-neutral. What workloads fit a spec-defined browser GPU API, and which do not? The fit question is really a question about the shape of the workload and where it runs. Good fits share a profile. They are embarrassingly parallel or map cleanly onto a grid of workgroups. They tolerate the explicit buffer-mapping round trip rather than demanding sub-millisecond host-device synchronisation. And they benefit from running on the client — image and video processing in-browser, particle and physics simulation for interactive visualisation, on-device inference for small-to-medium models where sending data to a server is a privacy or latency problem. For these, WebGPU turns a user’s idle GPU into free compute you do not have to provision. Poor fits also share a profile. Large-model training with multi-GPU collective communication needs NCCL-class primitives WebGPU does not expose. Workloads that depend on vendor-specific hardware — Tensor Cores, structured sparsity, transformer-engine kernels — hit the spec’s deliberate ceiling immediately, because those features are not portable and therefore not in the standard. Anything requiring tight, low-latency CPU-GPU coordination fights the asynchronous command model rather than riding it. A diagnostic checklist before you commit to WebGPU Run your candidate workload through these questions. Three or more “no” answers means WebGPU is probably the wrong layer. Does the deployment target include a browser, or a cross-vendor client fleet you do not control? If it is a single-vendor server fleet, the portability you are paying for has no buyer. Can the kernel express its performance within portable primitives, without Tensor Cores, warp-level intrinsics, or vendor extensions? Does the algorithm tolerate asynchronous submission and explicit buffer readback, rather than assuming synchronous launches? Is the model or data small enough that a single device’s memory and a portability-capped throughput are acceptable? Is the optimisation ceiling you measured at spec-evaluation time still above your performance requirement? That last point is the one teams skip. The right time to read the spec is before committing, because the spec tells you the ceiling. Reading it after you have built a CUDA-only codebase tells you only how much you will pay to unwind it. What is WebGPU’s performance and optimisation ceiling versus CUDA? Expect WebGPU to give you a large fraction of a GPU’s usable throughput for well-structured compute, while capping the top end you could reach with vendor-native tuning. In configurations we have looked at, the gap is not the API overhead — command submission is cheap — it is the inaccessibility of vendor-specific fast paths. You cannot invoke a Tensor Core matrix-multiply from WGSL because the abstraction that makes your code run on AMD and Intel is the same abstraction that hides NVIDIA’s specialised units. This is a structural ceiling, not an implementation immaturity that will disappear. A portable standard can only expose what all its targets support in common. As implementations mature, the floor rises — Dawn and wgpu keep closing the gap to native drivers on ordinary compute — but the ceiling is defined by the portability contract itself. That is the honest trade you are making, and it is quantifiable: at evaluation time you can measure how much of your workload runs through the portable path and what optimisation headroom you forfeit relative to a CUDA baseline. The measurable outcome worth chasing is a portability-versus-performance position stated in numbers, not adjectives: what percentage of the target workload runs across three vendors without a rewrite, and what the ceiling costs you. That framing sits inside the wider GPU engineering practice we work through with teams — it is one input to an API decision, not the whole decision. FAQ How does the WebGPU (www) spec work, and what does it mean in practice for GPU compute? The WebGPU specification defines a vendor-neutral API for both graphics and general-purpose GPU compute, exposed to JavaScript and increasingly to native code through libraries like wgpu. In practice it lets you write a compute kernel once — as a WGSL @compute shader — and dispatch it across NVIDIA, AMD, Intel, and Apple GPUs through the same API, with the browser or runtime translating to Vulkan, Direct3D 12, or Metal underneath. It is a genuine portability layer, not a graphics-only toy. What is the WebGPU specification, and who defines and maintains it? WebGPU is a W3C specification maintained by the GPU for the Web Community Group, with active participation from Google, Mozilla, Apple, and Microsoft. Because it is a standard rather than a single vendor’s runtime, its API contract is defined independently of any one GPU maker, and multiple implementations — notably Google’s Dawn and Mozilla’s wgpu — implement it against native platform drivers. How does WebGPU expose compute shaders, and how does its buffer and binding model differ from CUDA? WebGPU exposes compute through pipelines built from WGSL @compute entry points, with workgroups and invocations that map conceptually onto CUDA thread blocks and threads. The key difference is explicitness: every buffer carries a usage flag, every binding is validated against a bind group layout, and there are no raw device pointers or implicit unified memory. That explicit, validated model is the price of memory safety across vendors — and it makes porting a CUDA kernel a restructuring exercise, not a syntax translation. Where does the WebGPU spec sit relative to CUDA, OpenCL, and SYCL when I need portable GPU acceleration? WebGPU is the only one of the four that treats sandboxed, in-browser GPU compute as a first-class target, which makes it effectively the standards-backed choice for client-side deployment. CUDA offers the highest ceiling but only on NVIDIA hardware; OpenCL and SYCL are cross-vendor alternatives aimed at native rather than browser targets. The decision turns on your deployment surface and how much optimisation headroom you will trade for reach. What workload classes are a good fit for a spec-defined browser GPU API, and which are not? Good fits are embarrassingly parallel, tolerate asynchronous submission and explicit buffer readback, and benefit from running on the client — in-browser image and video processing, interactive simulation, and on-device inference for small-to-medium models. Poor fits are multi-GPU training with collective communication, workloads that depend on Tensor Cores or other vendor-specific hardware, and anything needing tight low-latency CPU-GPU coordination. What is the performance and optimisation ceiling of WebGPU compared with a vendor-native API like CUDA? WebGPU can deliver a large fraction of a GPU’s usable throughput for well-structured compute, but it caps the top end because it cannot expose vendor-specific fast paths like Tensor Cores from a portable shading language. This is a structural ceiling defined by the portability contract, not a temporary immaturity — the floor rises as implementations mature, but the ceiling stays fixed. The trade is quantifiable at evaluation time by measuring what runs through the portable path and what headroom you forfeit against a CUDA baseline. Can a WebGPU implementation run the same compute across NVIDIA, AMD, and Intel GPUs without a rewrite? Yes — that is the core reason to choose it. The same WGSL kernel and API calls run across NVIDIA, AMD, Intel, and Apple GPUs, because the implementation translates to each platform’s native driver. The caveat is that “without a rewrite” holds only for compute expressed within portable primitives; any reliance on vendor-specific hardware features falls outside the spec and cannot be reached from WebGPU at all. The question worth asking first Before you write a line against any of these APIs, the misconception to retire is that CUDA is the default and portability is an exotic requirement. For a growing set of deployment targets — anything client-side, anything cross-vendor — the reverse is true, and a CUDA-only codebase is the choice that needs justifying. The WebGPU spec is worth reading not because it will always win, but because reading it tells you the portability ceiling before you build on it. A GPU Performance Audit treats the API decision as a first-class dimension for exactly this reason: the failure class is not slow code, it is a memory model committed to before anyone measured what it would cost to change.
