WebGL Performance Optimization
Performance problems in WebGL games are almost always caused by one of four bottlenecks: too many draw calls overwhelming the CPU, too many state changes between draw calls, excessive fragment shader cost from high resolution or complex shaders, or memory bandwidth saturation from large or uncompressed textures. Diagnosing which bottleneck you are hitting determines which optimization techniques to apply.
Step 1: Reduce Draw Calls with Batching and Instancing
Every gl.drawArrays() or gl.drawElements() call incurs CPU overhead from driver validation, state checking, and command submission. In WebGL, the practical limit is roughly 1,000 to 3,000 draw calls per frame before the CPU becomes the bottleneck, depending on the device. Reducing draw call count is the single highest-impact optimization for most WebGL games.
Static batching combines multiple objects that share the same material into a single vertex buffer and draws them with one call. If your scene has 500 trees that all use the same shader and texture, merge their vertex data into one large buffer at load time. One draw call replaces 500, and the GPU processes the combined geometry just as efficiently.
Dynamic batching does the same thing at runtime for objects that move or change. This requires rebuilding the vertex buffer each frame, which has CPU cost, but the reduction in draw calls typically more than compensates. 2D sprite games benefit enormously from dynamic batching: instead of drawing each sprite individually, batch all sprites that share a texture atlas into a single draw call.
Instanced rendering (WebGL 2) draws many copies of the same mesh with a single call, using per-instance attribute data for position, rotation, scale, and color. This is ideal for grass, particles, crowds, and any scenario with many identical or similar objects. The vertex data is uploaded once, and per-instance transforms are stored in a separate buffer. The draw call specifies the instance count, and the GPU handles the rest.
Texture atlases pack multiple sprite images or material textures into a single large texture. This eliminates texture switches between draw calls, enabling batching of objects that would otherwise require separate textures. Most 2D game engines build texture atlases automatically, and tools like TexturePacker generate them for custom pipelines.
Step 2: Minimize State Changes
WebGL is a state machine, and every state change (switching shaders, binding textures, changing blend modes, updating uniforms) has cost. The driver must validate the new state and potentially flush the GPU pipeline. Minimizing state transitions between draw calls is the second most impactful optimization after reducing draw call count.
Sort by material. Before rendering, sort your draw list so that objects using the same shader program, texture, and blend mode are drawn consecutively. This groups state changes together, reducing the total number of transitions. The typical sort order is: shader program first (most expensive to switch), then texture, then other state.
Use Vertex Array Objects (VAOs) in WebGL 2 to bundle vertex attribute configuration into a single bind call. Without VAOs, you must re-call vertexAttribPointer and enableVertexAttribArray for every attribute of every mesh. With VAOs, one bindVertexArray() call restores the entire attribute setup.
Use Uniform Buffer Objects (UBOs) in WebGL 2 to share large blocks of uniform data between draw calls. Instead of setting the view and projection matrices individually for each object with gl.uniformMatrix4fv(), put them in a UBO and bind it once per frame. Per-object data (model matrix, material properties) goes in a separate UBO that changes per draw call.
Avoid redundant state calls. Track the current state in JavaScript and skip WebGL calls that would set the same value already active. If the current shader is already program X, do not call gl.useProgram(X) again. If texture unit 0 already has texture Y bound, skip the gl.bindTexture() call. This "dirty state" tracking is a standard technique in all WebGL engines.
Step 3: Optimize Textures and Memory
Texture data is the largest consumer of GPU memory and memory bandwidth in most games. Optimizing textures reduces memory usage, improves cache hit rates, and directly increases rendering performance.
Use compressed textures. WebGL supports several compressed formats through extensions: ETC1 (WEBGL_compressed_texture_etc1), ETC2 (WEBGL_compressed_texture_etc in WebGL 2), S3TC/DXT (WEBGL_compressed_texture_s3tc), and ASTC (WEBGL_compressed_texture_astc). Compressed textures use 4-8x less memory than uncompressed RGBA and decompress in hardware during sampling, costing no performance. The Basis Universal format (via the KTX2 container) can be transcoded to whichever format the device supports.
Generate mipmaps for all textures viewed at varying distances. Mipmaps are pre-scaled versions of a texture at 1/2, 1/4, 1/8 size, etc. When an object is far from the camera, the GPU samples a smaller mipmap level, reducing bandwidth and eliminating aliasing artifacts. Call gl.generateMipmap() after uploading the texture. The memory cost is 33% more than the base texture, but the performance and quality benefits are substantial.
Right-size your textures. A 4096x4096 texture uses 64MB of uncompressed GPU memory. If the object it covers never fills more than a quarter of the screen, a 1024x1024 texture looks identical and uses 4MB. Audit your textures and reduce dimensions to the minimum that looks acceptable at the viewing distances your game actually uses.
Avoid readbacks. Calling gl.readPixels() forces the GPU to finish all pending work and transfer data back to the CPU, creating a pipeline stall that can cost several milliseconds. If you need GPU data on the CPU (for picking, screenshot, physics), use asynchronous readbacks with WebGL 2 pixel buffer objects or defer the read to a non-critical frame.
Step 4: Write Efficient Shaders
Shader performance depends on the number of instructions per invocation, the number of texture samples, the precision of operations, and how many times the shader runs per frame (which depends on resolution and overdraw).
Move computation to the vertex shader where possible. The vertex shader runs once per vertex (typically thousands to tens of thousands per frame), while the fragment shader runs once per pixel (potentially millions per frame). Calculations that vary linearly across a surface (lighting direction, fog factor, simple color adjustments) can be computed per-vertex and interpolated by the rasterizer with negligible visual difference.
Use lookup textures to replace expensive math. If your shader computes a complex function (atmospheric scattering, subsurface scattering, procedural noise), precompute the results into a texture and sample it in the shader. A single texture lookup is cheaper than dozens of arithmetic operations, especially on mobile GPUs.
Reduce overdraw. Render opaque objects front-to-back (nearest first) so the depth test discards fragments behind already-rendered surfaces. This is called early-z rejection, and it prevents the fragment shader from running on hidden pixels. For transparent objects, render back-to-front with depth writing disabled. Minimize the number and coverage area of transparent objects, since they always cost full fragment shader execution.
Level of Detail (LOD) uses simpler meshes and shaders for distant objects. A character model might use 5,000 triangles when close to the camera but only 500 triangles at a distance. Similarly, distant objects can use a simpler shader without normal mapping or specular highlights. LOD transitions should be smooth (cross-faded or using screen-space error metrics) to avoid visible popping.
Step 5: Profile and Measure with Browser Tools
Optimization without measurement is guessing. Use browser developer tools to identify where your frame time is actually being spent before making changes.
The Chrome DevTools Performance panel shows a timeline of each frame, including JavaScript execution, WebGL calls, compositing, and idle time. Record a few seconds of gameplay, then examine individual frames. Long JavaScript blocks before the render indicate CPU bottlenecks. Frames that exceed 16.7ms total indicate you are missing the 60fps target.
Spector.js is a dedicated WebGL debugging extension that captures all WebGL calls for a single frame. It shows every state change, draw call, texture upload, and shader program switch in order. Use it to identify redundant state calls, unexpected draw call counts, and large texture uploads that should have happened at load time. Spector.js also lets you inspect individual draw calls, showing the geometry, textures, and shader code used.
The WebGL Inspector (available as a Chrome extension or bookmarklet) provides similar functionality with a focus on resource tracking. It shows all allocated textures, buffers, shaders, and framebuffers, helping you identify memory leaks and unused resources.
For GPU timing specifically, use the EXT_disjoint_timer_query_webgl2 extension (or EXT_disjoint_timer_query for WebGL 1). This lets you measure how long specific draw calls or render passes take on the GPU, separate from CPU time. Create a query object, begin and end it around the draw calls you want to measure, and read the result on a subsequent frame. This is the only way to accurately determine whether your game is CPU-bound or GPU-bound.
Profile first, optimize second. Reduce draw calls through batching and instancing, minimize state changes by sorting draw order, compress and right-size textures for bandwidth efficiency, keep fragment shaders simple, and verify every optimization with measurement tools.