Why First Run Scores Are Lower: Shader Compilation Explained
Why the first browser GPU run can be lower, how shader compilation affects FPS, and why public rows should use warm results.
The first benchmark run can be lower because the browser and driver may still be compiling and linking shader programs. Volume Shader BM Test uses a fragment shader with loop-heavy raymarching code, so the first run can include setup work that later runs do not repeat.
What happens before rendering
When a test mode starts, the browser creates WebGL shader programs. The driver compiles shader source, links it into a GPU program, allocates buffers and prepares the render path. Some of this cost happens before the first frame; some can still affect early frames.
How this affects the result
| Symptom | Likely cause | What to do |
|---|---|---|
| First run is lower than second run | Shader compile and cache warmup | Compare the second run |
| First seconds stutter, then stabilize | Driver pipeline setup | Watch P10 FPS and stability |
| Every run gets worse | Heat or battery throttling | Let the device cool |
| Score drops only on battery | Power policy | Plug in or disable battery saver |
Recommended protocol
Run the same mode once and treat it as warmup. Close the result panel. Run the same mode again under the same conditions. Record the second result. If the second and third results keep falling, the issue is probably thermal throttling rather than compilation.
Why this matters for public results
Public result rows should describe whether the run was a warm run, the browser used, the test mode and any obvious thermal condition. Without those fields, two rows with the same device name may not be comparable.
