GPU Compute, Web Workers, and Shader Demos: What Is Actually Measured?
Distinguish CPU Web Workers from WebGL rendering passes and choose measurements that answer a real GPU compute question.
GPU computation, JavaScript concurrency, and graphics rendering are different workloads. Similar-looking counters do not make their results interchangeable. Before choosing a test, identify where its work executes and what its timer includes.
The two compute demonstrations on this site
| Tool | Implementation | Output | Not measured |
|---|---|---|---|
| CPU Web Worker demo | JavaScript loop in worker threads; Canvas 2D progress display | Completed loop iterations, worker count, visualization FPS | GPU operations or TFLOPS |
| Texture compute demo | WebGL 2 fragment shaders update particle textures using alternating framebuffers | Browser FPS and workload settings | WebGPU compute throughput, CUDA performance, or standardized FLOPS |
The Worker demonstration runs a short mathematical loop repeatedly on CPU threads. Its iteration count is not an operations-per-second measurement. Worker timer scheduling, the runtime, and visualization all influence its behavior. Adding workers can increase overhead rather than improve useful throughput.
The texture demonstration performs GPU-side shader work through rendering passes. That is a legitimate graphics workload, but its FPS combines the update pass, particle rendering, browser scheduling, and display timing. It does not isolate a general compute kernel.
Choose a metric before running a test
For a real compute application, define the input, precision, required output, and completion condition. Measure elapsed time for a fixed workload or completed work per unit time. Verify the output as well as the timer. Document warm-up, compilation, transfers, and whether those costs belong in your result.
For example, an inference experiment needs a fixed model, input shape, batch size, and accuracy requirement. A rendering experiment needs the same scene and quality settings. An FPS number from a procedural shader cannot substitute for either measurement.
Avoid false conclusions about memory
The texture readback check compares sampled bytes from two WebGL reads. It is not a GB/s bandwidth benchmark. A flat throughput curve can have several causes, including scheduling or synchronization; it does not by itself prove a memory bottleneck.
What you can use these demos for
Use the Worker demo to observe how a browser remains responsive while CPU work runs on background threads. Use the texture demo to explore how rendering-pass settings affect this particle workload. For purchasing or production decisions, benchmark the actual application and record its versions and settings.
See Web Workers documentation, the WebGL API, and our methodology.