How to Record a Fair Browser Graphics Comparison
Build a repeatable browser benchmark record and keep frame-rate observations separate from GPU sensors, hardware scores, and application performance.
A useful benchmark result states what ran, under what conditions, and how consistently it repeated. A lone FPS number omits too much information to compare devices fairly. This guide gives a practical procedure for GPUtest.org's browser workloads.
Select the workload that answers your question
For per-pixel shader work, choose the volume shader demo. For repeated geometry, choose instancing. For a depth-map and filtering example, choose shadow mapping. Treat each as a separate workload with its own settings.
The Canvas particle demonstration combines JavaScript simulation and Canvas 2D drawing. It is useful for studying browser animation but does not isolate graphics-card speed. Likewise, CPU Web Workers are not GPU compute.
Control the observation
- Save work and close competing applications.
- Record browser, OS, power mode, viewport, and zoom.
- Select a workload and preserve its settings. For editable shader tests, preserve the code and camera too.
- Read the guide and start the workload. Allow a short warm-up before noting a fixed observation window.
- Repeat three times under the same conditions, recording every result.
The number of repeats is a practical method for noticing variation, not an AdSense rule or hardware certification standard.
Record the result without adding unavailable data
| Field | Source |
|---|---|
| FPS | Browser animation timing in the selected test |
| Object, particle, or instance count | The workload's settings or display |
| Temperature, clocks, or GPU utilization | Separate supported hardware monitor |
| Physical VRAM capacity | Device specifications or system reporting |
Do not substitute a texture-size estimate for physical VRAM use. Do not convert a frame count into TFLOPS without a defined operation count and a suitable timing method.
Compare repeated observations
Compare the same test and conditions. If one run is unusually slow, retain it and investigate competing work before discarding it. An auto-adjusting demo must be compared using workload count as well as FPS. A higher FPS at a smaller workload is not evidence of a faster device.
If FPS stays near display refresh, the browser may be limiting the rate. A native game or renderer can produce different results because its workload and graphics interface differ.
Use our methodology as a run-log checklist. Browser timing behavior is described in requestAnimationFrame documentation.