The support argument is over. WebGPU has been on by default in Chrome since version 113, along with Edge, Opera and Samsung Internet on the same Chromium base. Safari enabled it in version 26 across macOS, iOS, iPadOS and visionOS. Firefox turned it on for Windows first and extended to macOS afterward. MDN now documents it as a shipping feature rather than an experiment.
What it gives you is real. The entry point is navigator.gpu, you request an adapter and then a device, and the implementation maps that to Direct3D 12, Metal or Vulkan underneath. Shaders are written in WGSL rather than GLSL. Most importantly, there are compute pipelines, which WebGL 2 simply does not have, because WebGL 2 is a port of OpenGL ES 3.0 and that API predates the architectures every current GPU is built around.
The interesting question is no longer whether it works. It is which workloads actually needed it, and what a tab still cannot do that a native process can.
The Workloads That Justified the Work
Four categories are doing most of the pushing. Browser games shipping through engines rather than hand-written pipelines. Data visualization at counts where the draw call overhead of WebGL 2 becomes the bottleneck rather than the fill rate. In-browser inference, which is the clearest compute-shader use case on the platform. And real-money casino titles, which are the highest-volume sustained canvas workload on the consumer web and get discussed far less than the other three.
That last category is worth understanding, because the economics invert everything a hardware audience assumes. Return to player is configured at the math model level, certified by testing houses like GLI and by regulators including the MGA and UKGC, and published per title. Since operators largely run the same supplier catalogs, the rendering is effectively commoditized and players comparing sites do not evaluate visuals at all. They compare published return figures, which is why roundups of online casinos that payout rank on certified RTP and withdrawal processing rather than on presentation. The graphics stack is a cost center and the audited number is the product, which is roughly the inverse of how a GPU review works.
The technical constraints follow from that. When Flash was retired the entire slot and table catalog had to be rebuilt on HTML5 Canvas and WebGL, and most studios landed on PixiJS, a 2D WebGL renderer with a canvas fallback, often paired with Phaser for game structure and Spine for skeletal animation. A single title runs a continuous animation loop with layered sprite work, particle effects on win states and streamed audio, and it does so across sessions measured in hours rather than minutes, frequently on mid-range Android hardware over mobile data. Nothing on screen approaches a modern 3D scene, yet the sustained profile is demanding, and because presentation does not drive the purchase decision these studios optimize for battery and thermal headroom rather than peak frame rate.
None of those four categories is chasing higher fidelity. They are chasing lower CPU overhead, predictable frame pacing and the ability to run compute without a rendering pass. WebGPU delivers on all three, which is the honest case for it.
What a Tab Still Cannot Do
There is no reconstruction layer. Native rendering has spent five years moving work onto temporal upscalers, and the difference between preset generations is now large enough to change settings recommendations outright, as the DLSS 4 against DLSS 4.5 comparison in Cyberpunk 2077 demonstrates across quality modes. The browser has no equivalent. There is no vendor upscaler exposed through WebGPU, no frame generation, and no access to the tensor hardware that makes those techniques work. Whatever a page renders, it renders at output resolution.
Driver-level control is also absent by design. You cannot force a shader cache, cannot pick a queue priority the way a native application can, and cannot see the adapter in the detail a desktop profiler gives you. Pipeline compilation happens at runtime, so first-run stutter is a real characteristic of WebGPU content rather than an implementation bug, and the standard mitigation is to compile pipelines during a loading screen and hope the user does not skip it.
Then there is the platform floor. Chromium still keeps WebGPU behind a flag on Linux, Firefox has not enabled it there either, and mobile coverage depends on OS version and GPU vendor rather than on browser version alone. Validation messages differ between Dawn in Chromium and wgpu in Firefox, which means a shader that passes on one engine can fail on another for reasons that are correct in both.
The Fallback Tax
Because of that floor, WebGL 2 remains the baseline, and anything shipping to a general audience runs two renderers whether the developer wrote them or not. Three.js and Babylon.js both handle the switch automatically, which is convenient and also means the performance characteristics of your application differ by browser in ways you did not author and probably have not measured.
This is the part worth benchmarking properly. A WebGPU path and a WebGL 2 fallback on the same scene, on the same machine, with frametime capture rather than average FPS, will usually show that the WebGPU advantage is concentrated in draw call heavy scenes and close to nonexistent in simple ones. For a lot of content the correct answer is still WebGL 2, and the reason to move is compute access rather than raster throughput.
Two measurement notes if you run that test. Capture the first thirty seconds separately, because pipeline compilation contaminates any average that includes startup and it will flatter WebGL 2 by comparison. And test on a laptop on battery as well as a desktop, since browser rendering is one of the few workloads where the same page runs on a 450 watt desktop card and a thermally limited phone with no code path difference between them, and the results diverge more than a native benchmark ever would.
What Actually Changed
WebGPU is not a performance upgrade for browser graphics in general. It is a correctly designed API replacing one that was ported from a 2007 specification, and the practical gains are concentrated in specific shapes of workload: high draw call counts, and anything that wants the GPU without wanting a framebuffer.
For everything else the browser remains what it has been. A rendering environment with no reconstruction, no driver control, a compilation cost you cannot cache across sessions, and a hardware floor set by whichever device your least equipped user is holding. That is a reasonable set of constraints to build inside. It is not a rendering target in the sense this audience uses the term, and shipping WebGPU everywhere did not change that.