How to Test Shader Performance in a Web Browser

A shader performance test asks your GPU to do the one thing it is built for — running the same small program across millions of pixels every frame — and then measures how well it keeps up. If you have ever wondered why one effect runs buttery-smooth while another turns your fan into a jet engine, the answer almost always lives in the shader. This guide explains what shaders are, why fragment shaders dominate GPU load, and how to run a browser-based shader test and read its numbers without fooling yourself. No downloads, no drivers — just a WebGL canvas doing real work on your hardware.

What a shader actually is

A shader is a tiny program that runs on the GPU rather than the CPU. Modern graphics work is split into two main stages, and each has its own kind of shader.

A vertex shader runs once per vertex — the corner points that define the triangles making up a 3D scene. Its job is mostly geometry: transforming positions, applying camera projection, and passing data down the pipeline. A scene with a few thousand triangles runs the vertex shader a few thousand times per frame.

A fragment shader (sometimes called a pixel shader) runs once per pixel that a triangle covers on screen. Its job is colour: lighting, texturing, reflections, fog, procedural patterns, post-processing. This is where most visual richness comes from, and it is where the cost explodes. A single full-screen effect at a typical desktop resolution means the fragment shader executes millions of times every frame, and if you are running at 60 frames per second, that is hundreds of millions of shader invocations per second.

That asymmetry is the whole story of shader performance: geometry counts in thousands, pixels count in millions.

Why fragment shaders dominate GPU load

Because the fragment shader runs per pixel, its cost scales with two things multiplied together: how many pixels you are filling, and how much math each pixel costs.

The pixel count is driven by resolution. Double the width and height of your render target and you have roughly four times as many fragments to shade. This is why the same effect can feel effortless in a small window and punishing at native 4K.

The per-pixel cost is driven by ALU complexity — the arithmetic logic each invocation performs. A shader that samples one texture and multiplies it by a colour is cheap. A shader that does physically based lighting with multiple light sources, samples several textures, computes noise functions, or loops many times per pixel is expensive. Ray-marched effects, which step through a scene many times inside a single fragment, sit at the heavy end; if that interests you, the volume shader benchmark explores exactly that kind of per-pixel loop.

A good shader performance test deliberately pushes both levers so the GPU’s shading units become the bottleneck, rather than memory bandwidth or geometry throughput. That isolation is what makes the result meaningful.

What a browser shader test measures

Running in WebGL, a shader test renders a demanding fragment program to a canvas and times the results using the browser’s animation clock. From that timing it derives a handful of honest, reproducible numbers.

• Frames per second (FPS) — how many complete frames the GPU produced each second. Higher is better, but it is capped by your display’s refresh rate through vsync, so a smooth result may sit exactly at your monitor’s Hz.
• Frame time — how long a single frame took, in milliseconds. This is the more precise sibling of FPS and it is what you watch for spikes. A steady 16.7 ms line is far healthier than an average that hides stutters.
• 1% lows — the average of the slowest 1% of frames. This captures the hitches you actually feel even when the average looks fine.
• Frame-to-frame consistency — how tightly frame times cluster. Smoothness is consistency, not just a high average.

What the test cannot show you is just as important. A browser has no access to your GPU’s temperature, its utilisation percentage, its VRAM usage, or its power draw. Those readings require privileged system drivers that web pages simply do not have. Any browser tool that claims a live GPU temperature or utilisation figure is estimating or inventing it. What you can legitimately read is timing, and timing is enough to characterise shader throughput.

How to run a shader performance test

The process is short, and getting clean numbers is mostly about controlling the variables.

1. Open the tool. Launch the shader performance test in your browser. It compiles a fragment-heavy program and starts rendering immediately on your GPU.
2. Close competing work. Other tabs, video calls, and background renders all share the same GPU. Close them so the test has the hardware to itself.
3. Fix your window state. Decide whether you are testing windowed or full-screen and stay consistent, because resolution changes the pixel count and therefore the result.
4. Let it warm up. GPUs boost their clocks under load, and the first second or two of any run is not representative. Ignore the opening frames and read the numbers once the frame-time line settles.
5. Watch frame time, not just FPS. A flat frame-time trace means a healthy, consistent result. A jagged one means something is interrupting the GPU.
6. Change one thing at a time. If the tool lets you raise resolution or shader complexity, move a single setting per run so you can attribute the change to a cause.

Reading and comparing your results

The most reliable use of a shader test is comparison, not an absolute grade. Compare a run against another run: your laptop on battery versus on AC power, your machine before and after a driver update, or a light shader setting versus a heavy one. Because the workload is fixed, differences in frame time point to real differences in how your GPU handled the same instructions.

When a number moves, reason about the mechanism rather than guessing. Higher resolution raised the fragment count, so frame time went up. A laptop on battery capped its clocks to save power, so throughput fell. The GPU ran hot for a sustained period and the driver reduced clocks to stay in its thermal budget — a behaviour called throttling — so a run that started fast slowly degraded. You can observe every one of these effects through frame time alone, without any temperature reading, because the timing tells the story.

If your result is smooth and consistent, your GPU is comfortably keeping up with the per-pixel workload at that resolution. If frame times are high but steady, the workload simply exceeds what the hardware can do at that setting — lowering resolution or complexity will recover headroom. If frame times are erratic, look for a background process, a browser throttling a hidden tab, or thermal limits rather than assuming the GPU is weak.

A note on running heavy shaders

A demanding shader test keeps the GPU under a sustained, genuinely heavy load, which is the point — but it is worth being sensible about it. On a laptop, run on AC power and on a hard, flat surface so the fans can pull air; soft surfaces block the vents and encourage throttling. Phones and tablets have no fans and will throttle quickly, so treat mobile numbers as a snapshot rather than a sustained rating. If the device gets uncomfortably hot, the screen glitches, or the browser tab crashes, stop the test — nothing here requires you to push hardware to a worrying state to get a useful reading.

Frequently asked questions

What is the difference between a shader test and a full GPU benchmark?

A shader test isolates one part of the pipeline — per-pixel fragment work — so the result reflects shading throughput specifically. A broader GPU benchmark mixes geometry, textures, and effects to approximate a whole workload. Use a shader test when you want to know how your GPU handles heavy per-pixel math; use a broader benchmark for an overall picture.

Why does my FPS stop exactly at 60 (or 120)?

That is vsync doing its job. The browser synchronises frames to your display’s refresh rate, so FPS is capped at your monitor’s Hz even if the GPU could draw more frames. A result pinned at your refresh rate with steady frame times means the shader is running comfortably, not that the GPU is maxed out.

Can a browser shader test read my GPU temperature?

No. Web pages cannot access temperature, utilisation, VRAM, or power sensors — those need system-level drivers. A shader test measures timing (FPS, frame time, 1% lows). You can infer that the GPU is throttling from frame time slowly rising under sustained load, but the actual temperature is not something the browser can see.

Which matters more, vertex or fragment shader performance?

For most modern effects, fragment shader performance dominates because it runs per pixel and scales with resolution. Vertex work matters for extremely high-polygon scenes, but per-pixel lighting, texturing, and post-processing are usually the bottleneck, which is why shader tests lean on fragment-heavy workloads.

Why do my results change between runs?

Clock boosting, thermal state, battery versus AC power, and background activity all shift the numbers. The first run after the GPU has been idle often looks different from a run when it is already warm. For fair comparisons, keep resolution, power source, and window state identical, and let the test warm up before reading.

Shaders are where visual complexity turns into GPU cost, so testing them tells you more about real graphics performance than almost any single number. When you are ready to see how your hardware handles heavy per-pixel work, run the shader performance test and watch the frame-time line — and if you want to understand the API underneath it all, the WebGL performance test guide is the natural next step.