Back to Blog
Volume Shader field report2026 editionGPUBenchmarkingWebGPUWebGLAnalytics

Browser GPU benchmark report

What 32,604 GPU Benchmarks Reveal About the Web in 2026

This browser GPU benchmark report analyzes 32,604 real submissions, covering WebGPU adoption, mobile dominance, performance tiers, and data quality signals.

Report frame

2026-04-14
Volume Shader Team
11 min read
Dataset window: 2025-10-10 to 2026-04-13

73.6%

of all submissions came from mobile devices

86.2%

of all runs used WebGPU rather than WebGL2

84%

of the dataset came from entry-tier GPUs

10,750

submissions were recorded in March 2026 alone

28,713

runs were marked preset-relevant by the fairness layer

Key takeaway

This is not mainly a story about halo GPUs. It is a story about whether browser graphics holds up on mainstream hardware, under real-world thermal, browser, and preset constraints.

Overview

Read this like a market report, not a lab shootout

The dataset is observational. That makes it messier than a controlled benchmark, but much closer to how browser graphics is actually experienced by real users.

What this report is good at

Spotting market structure, product priorities, and confidence limits.

The trend lines matter more than any single brag number because browser mix, fallback behavior, thermals, and session conditions all leak into production data.

Safe claim: the web graphics audience is mobile-heavy, entry-tier-heavy, and WebGPU-first.

Overview infographic for the browser GPU benchmark report

Method

A production submission report with clear confidence boundaries

We queried the production Prisma-backed samples table and framed the results to show what the benchmark is strong at, and where the claims must stay conservative.

What the table stores

  • FPS and frame-time metrics
  • Browser and OS metadata
  • GPU adapter strings and backend information
  • Preset selections, device tiers, and relevance flags

The analytics_events table currently has zero stored rows, so this is a submission report, not a full funnel report.

DimensionValue
Submission count32,604
Analytics events persisted0
Primary browserChrome
Dominant device classMobile
Dominant APIWebGPU

Caveats that matter

The cohorts are not perfectly matched across API, browser, hardware, and thermal state.

Peak values should be treated carefully because the dataset contains meaningful outliers.

Interpretation rule: trust the trend lines, not every single brag number.

Mobile gravity

The real center of gravity is the everyday Android phone

The benchmark's defining fact is not a flagship desktop score. It is the device mix.

Out of 32,604 submissions

23,990

mobile devices

8,492

desktop devices

122

other bucket

That means mobile represented 73.6% of the full dataset. The benchmark’s center of gravity is not the RTX 4090. It is the mass-market phone GPU trying to survive a shader-heavy workload inside tighter thermal, power, and browser constraints.

High-volume GPU

Mali-G57 MC2

3,151 samples

High-volume GPU

Mali-G615 MC2

1,569 samples

High-volume GPU

Adreno 830

1,265 samples

High-volume GPU

Mali-G52 MC2

1,214 samples

Device and API mix chart for the browser GPU benchmark report

Editorial read

This is a mass-market device profile, not a boutique enthusiast profile.

The real UX question is whether ordinary devices can sustain the workload at all, and under which presets.

GPUMedian FPSInterpretation
Mali-G615 MC681.0Comfortable for an interactive workload
Adreno 83076.0Strong high-end mobile result
Mali-G57 MC234.0Playable, but clearly mid-tier
Mali-G52 MC218.3Borderline for a smooth experience
Adreno 6104.7Not viable for this workload
PowerVR Rogue GE83205.4Also not viable

Runtime split

WebGPU is the main road now, but the dataset still needs careful reading

The API split is no longer subtle. WebGPU is the default runtime path across both desktop and mobile in this audience.

API share

28,092 submissions used WebGPU.

4,512 submissions used WebGL2.

WebGPU accounted for 86.2% of all recorded runs.

By device type

Desktop: 92.9% WebGPU

Mobile: 84.1% WebGPU

WebGL2 remains important as a fallback, not as a replacement narrative.

Backend distribution

Vulkan: 19,020 samples

ANGLE-D3D11: 7,694 samples

ANGLE-OpenGL ES: 1,683 samples

ANGLE-Metal: 215 samples

Practical reading

At lighter presets, WebGPU wins clearly in aggregate.

At heavier presets, the gap narrows or reverses.

That does not prove WebGL2 is stronger. It proves mixed-population production data needs controlled interpretation.

PresetWebGPU avg FPSWebGL2 avg FPSRatio
Ultra Low56.035.21.59x
Balanced35.723.31.53x
Reset32.127.71.16x
High23.424.40.96x
Very High19.720.80.95x
Extreme14.516.10.90x
Insane7.49.40.78x

Preset strategy

Presets are doing real product work, not just organizing the chart

Preset-aware interpretation is what keeps this benchmark from collapsing into a flat pile of incomparable numbers.

Ultra Low

26,244

Balanced

1,471

High

1,232

Low

1,144

Very High

955

Relevant for preset

28,713

Ultra Low is the benchmark’s true front door.

If nearly the entire dataset funnels through one preset, that preset is not just a convenience option. It is the main onboarding surface. The fairness filter is reducing apples-to-oranges comparisons between entry-class mobile silicon and much stronger desktop GPUs on mismatched difficulty targets.

Desktop GPUMedian FPS
NVIDIA GeForce RTX 506098.2
NVIDIA GeForce RTX 406082.8
NVIDIA GeForce RTX 405071.6
NVIDIA GeForce RTX 3050 6GB55.6
Intel Iris Xe Graphics11.5

Data quality

The dataset is valuable, but not clean enough for absolute claims

The fill rates are strong enough for product direction and content strategy, but several telemetry signals still need cleanup before the claims can get louder.

Malformed OS strings

23,833

Duplicate groups

2,288

Rows inside duplicate groups

5,539

FPS spikes above 180

419

The max-FPS story is weaker than the median-FPS story.

Adapter fill rate is 99.9%. Browser and OS fill rates are 100%. Backend fill rate is 88.3%. The trend lines are real, but the confidence bands are uneven, and the current stability metric is not ready to carry the narrative on its own.

Data quality risk summary for the browser GPU benchmark report

Roadmap

What Volume Shader should do next

If this report is treated as a product input rather than just a content asset, the next actions become fairly obvious.

1

Treat mobile as the primary benchmark audience

Android Chrome and Vulkan-class backends should be the core path, not a secondary compatibility lane.

2

Keep WebGL2 healthy

WebGPU is the default path, but WebGL2 still matters for coverage, regression defense, and broader browser support.

3

Tighten public segmentation

Device class, preset, API, and tier should all shape how public results are presented.

4

Clean telemetry before louder claims

OS normalization, duplicate suppression, outlier clipping, and a better stability metric would strengthen every future report.

5

Publish more analysis, not just more scores

The current dataset already supports monthly snapshots, preset guides, mobile GPU spotlights, and browser comparison breakdowns.

FAQ

The short answers decision-makers usually need

This is the compact interpretation layer for teams reading the benchmark as product evidence.

What does this benchmark actually measure?

It measures real-time rendering throughput under a shader-heavy browser workload, using FPS, frame time, preset metadata, adapter strings, and environment context.

Is this report mainly about mobile or desktop?

In practice it is mainly about mobile. 73.6% of all submissions in the analysis window came from mobile devices.

Does this prove WebGPU always beats WebGL2?

No. It shows that WebGPU is the dominant runtime path in this production dataset, not that it universally wins under perfectly matched lab conditions.

What should teams do with this report?

Use it for product prioritization, preset strategy, telemetry cleanup, and editorial direction rather than as a simplistic universal winner chart.

Bottom line

Browser GPU benchmarking is now a mainstream web performance problem, shaped more by mobile volume, entry-tier hardware, preset design, and telemetry hygiene than by a narrow set of flagship desktop scores.