WebGL 1.0 shipped in 2011 and it is still the default a lot of browser games are built against. That default is quietly expensive, because the version that replaced it changed what a browser can render, not just how fast it renders it.
WebGL 2.0 arrived in 2017, based on OpenGL ES 3.0, and the last real holdout on support has since closed that gap. For most new projects it is now a reasonable default target with 1.0 kept as a fallback.
The Version Split Still Costs Projects Performance
WebGL 1.0 gives you the core of 3D rendering: vertex and fragment shaders, texture mapping, framebuffer objects for render to texture, and basic blending and depth testing. It runs on essentially every GPU made after 2008, which is why its support numbers look so good.
The catch is that a lot of the techniques people reach for on 1.0 are workarounds. Instanced rendering arrives through an extension. Non power of two textures come with restrictions. Sharing large blocks of uniform data between shader programs means setting them one at a time. None of those are problems on 2.0, so a project that targets 1.0 for reach is often paying in frame time for users who would have been fine either way.
Why Multiple Render Targets Matter
The single biggest addition in WebGL 2.0 is Multiple Render Targets, which lets one fragment shader write to several textures in the same pass. That sounds like plumbing, and it is the foundation of deferred rendering.
In a deferred pipeline the first pass writes geometry information, position, normal, albedo and roughness, into separate textures called the G-buffer. A second pass then does the lighting using that data. The cost of lighting stops scaling with the number of objects and starts scaling with screen pixels, which is how you light a scene with dozens of dynamic lights instead of a handful.
Transform feedback lands in the same release and matters for the same reason. It captures vertex shader output back into a buffer, so particle systems and simple physics can run entirely on the GPU without a read back to the CPU.
The Sandbox Rules You Design Around
WebGL runs inside the browser security sandbox, and that shapes the API more than most tutorials admit. The GPU is shared, so the browser has to assume a shader could try to read memory it does not own or hang the driver.
The practical consequences show up as things that feel arbitrary until you know why. Context loss is a real state you have to handle rather than an edge case, cross origin textures need proper headers before you can sample them, and long running shaders can be killed. Designing for those from the start is much cheaper than retrofitting them after a launch.
Where WebGPU Fits
WebGPU is the successor, and it is genuinely better for compute heavy work and for cutting driver overhead on large scenes. It is also not a reason to skip WebGL 2.0.
Engines are shipping WebGPU renderers with WebGL 2.0 fallbacks, which means the fallback path is the one most of your players will actually run for a while yet. Understanding the WebGL 2.0 pipeline is what lets you reason about both, since the concepts carry over almost entirely.
The Practical Takeaway
If you are starting a browser game now, target WebGL 2.0 and keep 1.0 as a fallback rather than a baseline. The reach argument that justified 1.0 defaults has mostly expired, and the features you get in exchange, instancing, uniform buffer objects and multiple render targets, are the ones that decide how the finished game looks and how it holds a frame rate. We wrote the full pipeline up in more detail, including the version split and the WebGPU transition, in our WebGL game development guide.
Top comments (0)