When WebGL Beats the DOM for Complex UI Rendering_

Most frontend performance problems do not require WebGL.

If you are animating a card stack, a tooltip, or even a moderately busy chart, the DOM is usually the right abstraction. It is easier to debug, easier to make accessible, and easier to keep integrated with the rest of your product.

WebGL becomes interesting when the browser is spending more time managing thousands of visual primitives than your application is spending on the actual product logic. That usually shows up as some combination of these symptoms:

• Frame time spikes during style recalculation or paint
• SVG nodes or canvas draw calls grow into the tens of thousands
• Interactions become noticeably worse on ordinary laptops, not just on your dev machine
• The UI is visually simple, but the rendering workload is large

That is the point where "optimize the React component" stops being a serious plan.

What Changes When You Move to WebGL

With DOM or SVG rendering, the browser owns a lot of work for you:

• layout
• style resolution
• hit testing
• painting
• compositing

That convenience has a cost. Every element participates in browser pipelines that were designed for documents first and graphics second.

WebGL takes the opposite trade-off. You upload geometry and per-instance data to GPU buffers, write shaders to tell the GPU how to draw, and keep the browser out of the hot path. You lose convenience, but you gain control over throughput.

For dense, animated scenes, that trade can be worth it.

The Performance Problem You Are Actually Solving

The common mistake is to think "WebGL is faster" as a general rule. It is not.

WebGL is faster when:

• the scene contains many similar visual objects
• those objects can be represented as structured numeric data
• the work is mostly drawing, interpolation, transforms, or color calculations

WebGL is often the wrong tool when:

• the scene is mostly text
• accessibility semantics matter at the element level
• you need native browser layout behavior
• the complexity is in data fetching or state churn, not rendering

A good example is a telemetry view with thousands of moving points. A bad example is a marketing page with six decorative blobs.

A Minimal WebGL Setup

The first step is just getting a predictable rendering surface:

const canvas = document.querySelector("canvas");
const gl = canvas?.getContext("webgl2");

if (!gl) {
  throw new Error("WebGL2 is not available in this browser");
}

function resizeCanvas() {
  const dpr = window.devicePixelRatio || 1;
  const width = Math.floor(canvas.clientWidth * dpr);
  const height = Math.floor(canvas.clientHeight * dpr);

  if (canvas.width !== width || canvas.height !== height) {
    canvas.width = width;
    canvas.height = height;
    gl.viewport(0, 0, width, height);
  }
}

resizeCanvas();
window.addEventListener("resize", resizeCanvas);

Two details matter here:

• You size the backing buffer with devicePixelRatio, not just CSS pixels.
• You call gl.viewport(...) after resizing, or your scene will render with stale dimensions.

The Real Win: Keep Data on the GPU

The biggest WebGL performance improvement usually does not come from a clever shader. It comes from avoiding unnecessary CPU-to-GPU traffic.

This is the kind of update path that quietly kills performance:

function renderFrame(points: Float32Array) {
  const buffer = gl.createBuffer();
  gl.bindBuffer(gl.ARRAY_BUFFER, buffer);
  gl.bufferData(gl.ARRAY_BUFFER, points, gl.STATIC_DRAW);
  gl.drawArrays(gl.POINTS, 0, points.length / 2);
}

It reallocates resources on the hot path. That is the GPU equivalent of rebuilding the world every frame.

A healthier pattern is to allocate once and update in place:

const positionBuffer = gl.createBuffer();
gl.bindBuffer(gl.ARRAY_BUFFER, positionBuffer);
gl.bufferData(gl.ARRAY_BUFFER, MAX_POINTS * 2 * Float32Array.BYTES_PER_ELEMENT, gl.DYNAMIC_DRAW);

function updatePoints(points: Float32Array) {
  gl.bindBuffer(gl.ARRAY_BUFFER, positionBuffer);
  gl.bufferSubData(gl.ARRAY_BUFFER, 0, points);
}

If the point count is bounded, preallocation is usually the right default.

Shaders Are Just Programs

WebGL feels intimidating until you stop thinking of shaders as "graphics magic" and start thinking of them as small programs with strict inputs and outputs.

A vertex shader decides where something lands on screen:

#version 300 es
in vec2 a_position;
uniform vec2 u_resolution;

void main() {
  vec2 zeroToOne = a_position / u_resolution;
  vec2 zeroToTwo = zeroToOne * 2.0;
  vec2 clipSpace = zeroToTwo - 1.0;

  gl_Position = vec4(clipSpace * vec2(1.0, -1.0), 0.0, 1.0);
  gl_PointSize = 4.0;
}

A fragment shader decides how the resulting pixels look:

#version 300 es
precision highp float;

out vec4 outColor;

void main() {
  vec2 p = gl_PointCoord - vec2(0.5);
  float distanceFromCenter = length(p);
  float alpha = smoothstep(0.5, 0.0, distanceFromCenter);

  outColor = vec4(0.14, 0.72, 0.97, alpha);
}

That is enough to render soft circular points without asking the DOM to manage thousands of elements.

Where React Still Fits

Moving rendering to WebGL does not mean removing React from the application.

The clean split is:

• React owns controls, filters, layout, and data loading
• WebGL owns the dense drawing surface

That usually means treating the canvas as an imperative island:

import { useEffect, useRef } from "react";

export function PointCloud({ points }: { points: Float32Array }) {
  const canvasRef = useRef<HTMLCanvasElement | null>(null);
  const rendererRef = useRef<Renderer | null>(null);

  useEffect(() => {
    if (!canvasRef.current) return;
    rendererRef.current = new Renderer(canvasRef.current);

    return () => {
      rendererRef.current?.dispose();
      rendererRef.current = null;
    };
  }, []);

  useEffect(() => {
    rendererRef.current?.update(points);
  }, [points]);

  return <canvas ref={canvasRef} className="h-full w-full" />;
}

That pattern keeps React out of the per-frame rendering loop, which is usually what you want.

The Problems People Forget

WebGL projects often fail for reasons that have nothing to do with shader math:

• Context loss is real. You need to handle webglcontextlost and webglcontextrestored.
• Text rendering is awkward. Labels often need a second layer or a hybrid DOM approach.
• Debugging is slower than regular frontend work.
• Accessibility does not come for free.
• GPU memory leaks are still leaks, even if Chrome DevTools does not make them as obvious.

If the product needs semantic DOM structure, keyboard navigation, and screen-reader-friendly content for each visual node, a pure WebGL surface is usually the wrong shape.

A Practical Rule

Use the simplest rendering model that can meet the workload.

Start with the DOM or SVG if you can. Move to Canvas when you need a lower-level draw loop. Move to WebGL when the problem is large-scale rendering and the GPU can actually help.

That sequence is not dogma. It is just a good way to avoid solving a document problem with a graphics pipeline.

Further Reading

• MDN: WebGL API
• MDN: WebGL best practices
• MDN: WebGLRenderingContext.isContextLost()