How We Cleaned 4,931 Browser GPU Benchmark Samples

Volume Shader BM removed 4,931 low-quality browser GPU benchmark samples from its live benchmark database in July 2026. The cleanup targeted impossible performance metrics, duplicate submission bursts, and invalid preset records while preserving legitimate mobile GPU families such as Mali, Adreno, Maleoon, and Xclipse.

This is a data quality report, not a marketing claim. The goal is to document exactly what changed, why it changed, and how the cleanup makes the public GPU leaderboard more reliable for WebGPU, WebGL2, mobile GPU, and desktop GPU comparison.

Executive summary

Metric	Before cleanup snapshot	After cleanup live snapshot	Change
Total benchmark samples	50,414	45,493	-4,921 live rows
Rows deleted by cleanup job	-	4,931	9.8% of the audited snapshot
Authoritative leaderboard rows	Not the primary audit output	40,503	Current eligible pool
Non-relevant preset rows retained	Not deleted	4,990	Retained but excluded from ranking
Invalid metric rows after cleanup	Present before cleanup	0	Cleared
Invalid preset rows after cleanup	329 Reset rows	0	Cleared
Missing API, browser, or OS context after cleanup	0	0	Clean

The deletion event itself moved the database from 50,414 rows to 45,483 rows. The post-cleanup live snapshot used in this report shows 45,493 rows because new benchmark submissions continued to arrive after the cleanup window.

What is browser GPU benchmark data quality?

Browser GPU benchmark data quality is the process of deciding which submitted test runs are reliable enough to influence public rankings. A valid browser GPU sample should have plausible FPS and frame-time values, a known preset, enough browser and operating-system context, and no short-session duplicate abuse.

That matters because browser benchmarks are not lab tests. They are affected by browser support, driver behavior, mobile thermals, background tabs, battery state, and user behavior. More rows are useful only when the rows can be compared responsibly.

Why this cleanup was necessary

Volume Shader BM is a live WebGPU and WebGL2 benchmark. Users submit real browser runs from phones, laptops, desktops, and integrated GPUs. That gives the dataset practical value, but it also creates noise.

The July 2026 audit found three problems worth cleaning:

1. Impossible or misleading metrics: Some samples had fpsMax or frameTime values outside acceptable benchmark bounds.
2. Duplicate submission bursts: Some sessions submitted repeated rows inside the same short time window, which can overweight one device or one test session.
3. Invalid preset records: Reset is not a meaningful benchmark preset and should not appear as a public comparison bucket.

The cleanup did not remove rows simply because a GPU name looked unfamiliar. That distinction is important: mobile GPU strings are messy, and legitimate adapters such as Mali, Adreno, Maleoon, and Xclipse should not be punished by a narrow desktop-first validator.

Cleanup methodology

The cleanup used a backup-first workflow.

1. Audit the live samples table with explicit data quality rules.
2. Export a full local backup of every candidate row before deletion.
3. Delete only backed-up row IDs, not a freshly recalculated moving target.
4. Re-run the same cleanup rules to confirm there were no remaining candidates.
5. Run an independent SQL audit for metric bounds, required context, and preset validity.

What counted as a cleanup candidate?

Rule	Why it matters	Action
fps, fpsMin, fpsMax, frameTime, duration, or stability outside accepted bounds	Impossible values distort rankings and averages	Delete
presetName empty or Reset	Not a valid public benchmark bucket	Delete
Missing api, browserName, or os	Too little context for public comparison	Delete if present
Obvious URL, social, gambling, or adult spam in GPU identity fields	Prevents data pollution	Delete if present
Same session, GPU identity, preset, browser, API, and 10-minute bucket with more than two rows	Prevents repeated short-window submissions from overweighting one run	Keep latest 2, delete the excess
isRelevantForPreset=false	A fair-ranking exclusion, not dirty data	Retain

No spam GPU identity rows were found in this pass. No rows were deleted solely because of GPU model naming.

Cleanup reasons: what was removed?

The cleanup removed 4,931 rows. Reason counts can overlap because one row may be both a duplicate and have an invalid metric.

Cleanup reason	Flagged rows	Meaning
Invalid benchmark metrics	2,655	FPS, frame-time, duration, or stability values outside accepted bounds
Duplicate excess	2,144	Repeated rows in the same short-session comparison bucket, after keeping the latest two
Invalid preset	329	Reset or blank preset values

Preset distribution before and after cleanup

The strongest visible change was the removal of invalid Reset rows and a reduction in noisy Ultra Low duplicates. Ultra Low remains the largest preset because it is the most accessible entry point for mobile and low-power devices.

Preset	Before cleanup	Removed	After cleanup live snapshot
Ultra Low	40,461	2,808	37,662
Balanced	2,340	349	1,992
High	1,995	347	1,648
Low	1,883	286	1,597
Very High	1,459	279	1,180
Insane	979	263	716
Extreme	968	270	698
Reset	329	329	0

Interpretation: the cleanup did not change the shape of the benchmark audience. It sharpened the dataset by removing rows that should not carry public ranking weight.

API distribution before and after cleanup

WebGPU remains the dominant path after cleanup. The distribution changed only slightly because the cleanup targeted quality, not API share.

API	Before cleanup	Removed	After cleanup live snapshot
WebGPU	43,715	4,161	39,564
WebGL2	6,699	770	5,929

Before cleanup, WebGPU represented 86.7% of the audited snapshot. After cleanup, WebGPU represented 87.0% of the live snapshot. That tells us the cleanup did not manufacture a WebGPU narrative; WebGPU was already the main runtime path in this browser GPU benchmark dataset.

Current top GPU sample families after cleanup

The post-cleanup top sample families still show the same important market signal: Volume Shader BM is heavily shaped by real mobile and integrated GPU usage, not only flagship desktop cards.

GPU family	Current sample count
Mali-G57 MC2	3,563
Mali-G615 MC2	1,794
Intel UHD Graphics	1,534
Adreno 830	1,444
Mali-G52 MC2	1,435
Mali-G57	1,052
Mali-G615 MC6	1,014
ARM, Mali-G57 MC2	902
Adreno 750	898
Adreno 610	820
Mali-G68	802
Mali-G720 MC7	775

This is why GPU-name-based deletion would have been the wrong approach. A benchmark built for the open web must expect mobile adapter strings, vendor-specific naming, and inconsistent renderer labels.

What stayed in the database?

The cleanup intentionally retained 4,990 rows marked isRelevantForPreset=false. These rows are not treated as authoritative leaderboard evidence, but they are still useful for transparency, result pages, and future analysis.

Keeping these rows is the right tradeoff. A sample can be real while still being a poor fit for a particular public ranking bucket. Deleting every non-ranking row would make the dataset look cleaner, but it would also erase useful context about how users actually test their devices.

What changed for the public leaderboard?

The public leaderboard is now safer to read in three ways.

1. No invalid Reset bucket: public preset comparison no longer has a meaningless preset bucket.
2. No impossible metric rows: post-cleanup verification found zero rows with invalid FPS, frame-time, duration, or stability bounds.
3. Less short-session overweighting: duplicate bursts are reduced by keeping only the latest two rows in each short comparison bucket.

The result is not a perfect lab dataset. It is a better live benchmark dataset: cleaner, easier to explain, and more defensible when cited in GPU benchmark reports.

What did the verification show?

After deletion, the cleanup rule found 0 remaining candidates. A separate SQL audit also returned zero rows for the following categories:

Validation check after cleanup	Remaining bad rows
fps outside accepted bounds	0
fpsMin outside accepted bounds	0
fpsMax outside accepted bounds	0
frameTime outside accepted bounds	0
duration <= 0	0
stability outside 0-100	0
Invalid or blank preset	0
Missing API	0
Missing browser name	0
Missing OS	0

That verification matters more than the deletion count. A large cleanup is only useful if the resulting dataset can be audited again and come back clean.

Why this improves SEO and AEO value

Search engines and AI answer engines prefer content that is specific, fresh, and backed by original data. This cleanup gives Volume Shader BM a stronger evidence base for queries such as:

• browser GPU benchmark data
• WebGPU benchmark leaderboard
• WebGL2 benchmark results
• mobile GPU benchmark online
• browser benchmark data quality
• GPU leaderboard methodology
• how to compare WebGPU and WebGL performance

For answer engines, this report is designed to be extractable. It includes a direct summary, before-and-after tables, methodology, validation checks, and FAQ answers. For traditional SEO, it strengthens topical authority around benchmark trust, data quality, WebGPU performance, and browser-based GPU testing.

What this does not prove

This cleanup does not prove that one GPU, browser, or graphics API is universally better than another. It also does not turn a live community benchmark into a controlled lab test.

The safer claim is narrower and stronger: Volume Shader BM now has a cleaner public benchmark corpus, with invalid metric rows and duplicate excess rows removed, while preserving legitimate mobile GPU data and non-ranking context.

Practical guidance for reading Volume Shader BM results

Use the leaderboard as a confidence-aware comparison surface.

• Compare runs inside the same preset.
• Separate mobile and desktop device classes.
• Prefer stable repeated results over one unusually high score.
• Treat isRelevantForPreset=false as a ranking caveat, not a fake-result label.
• Use public result pages and the methodology page when citing a benchmark claim.

You can run a fresh benchmark on the GPU test page, compare current rankings on the live leaderboard, and review measurement rules on the methodology page.

FAQ

Why did Volume Shader BM delete benchmark samples?

Volume Shader BM deleted benchmark samples that could distort public rankings: impossible metric values, duplicate bursts from the same short session, and invalid preset records. The cleanup improves leaderboard trust without deleting legitimate GPU families based on name alone.

Were mobile GPUs removed from the benchmark?

No. Mobile GPU names were not treated as dirty data. The cleanup preserved legitimate mobile adapter families such as Mali, Adreno, Maleoon, and Xclipse. Rows were removed because of metric validity, duplicate excess, or invalid preset state, not because a GPU family was mobile.

Why keep rows that are not relevant for a preset?

isRelevantForPreset=false means a sample should not affect a specific fair-ranking leaderboard. It does not mean the sample is fake. Keeping those rows preserves transparency and helps future analysis while preventing mismatched results from changing the ranking.

Does the cleanup change WebGPU vs WebGL2 conclusions?

No. WebGPU remained the dominant API before and after cleanup, moving from 86.7% of the audited snapshot to 87.0% of the live post-cleanup snapshot. The cleanup improved data quality; it did not create the WebGPU trend.

How often should a live GPU benchmark dataset be cleaned?

A live GPU benchmark dataset should be audited whenever leaderboard rules change, duplicate behavior appears, or public reports depend on the data. For a growing benchmark, a monthly quality pass is a reasonable baseline, with immediate cleanup for severe metric or spam issues.

Bottom line

Benchmark trust is not created by publishing a bigger number. It is created by showing which rows count, which rows do not count, and why.

The July 2026 cleanup removed 4,931 low-quality samples from Volume Shader BM, cleared invalid metric and preset rows to zero, preserved legitimate mobile GPU data, and left a stronger foundation for WebGPU and WebGL2 leaderboard analysis.

That makes the benchmark more useful for users, more defensible for reports, and more citable for search engines and AI answer engines.