1. Controlled workload generation
A sustained WebGL shader workload runs at the selected resolution, quality, and target FPS profile.
Methodology
How This Benchmark Produces Signals
This page documents how WebGPUStress generates workload, samples frame data, derives metrics, and maps results to practical interpretations. Use it when you need reproducible comparisons instead of one-off score snapshots.
Methodology version: M-2026.03
2. Continuous frame sampling
During the run, each sample records frame rate, frame-time distribution, and below-target behavior.
3. Derived metric synthesis
Average FPS, 1% Low FPS, frame-time spread, and drop ratio are calculated from the sample stream.
4. Stability scoring pass
A normalized stability score (0-100) summarizes pacing quality and below-target persistence.
5. Human-readable assessment
Threshold logic maps raw metrics into practical run categories: Healthy, Watch Closely, or Unstable.
Metric Definitions
| Metric | What it represents | Interpretation caution |
|---|---|---|
| Average FPS | Sustained throughput for the selected profile. | High average alone does not guarantee smooth pacing. |
| 1% Low FPS | Performance at the slowest sustained moments. | Large gap vs average suggests stutter risk. |
| Frame Time Spread (P95-P50) | Consistency window for frame delivery. | Rising spread often indicates instability under load. |
| Drop Frame Ratio | Time fraction below the selected target FPS. | High ratio usually means profile overload or throttling. |
| Stability Score (0-100) | Combined consistency indicator across the run. | Always interpret with profile settings and run duration. |
Reproducibility Checklist
- Keep browser version, GPU driver version, and power mode fixed.
- Run at least two identical profiles before comparing hardware changes.
- Keep the benchmark tab in focus for the full run.
- Do not compare scores across different browsers as if they were equivalent.
- Use desktop telemetry (MSI Afterburner or GPU-Z) for temperatures and clocks.
How this FPS test works
Average FPS = 1,000 × interval count / measured milliseconds. Quantiles use linear interpolation at (N − 1) × p. 1% Low = 1,000 / mean of the longest ceil(N × 0.01) intervals, not 1,000/P99.
Run a lightweight FPS testGraphics detection, reports and fair comparisons
GPU Detector and Hardware Acceleration Test share the WebGPU and WebGL workload validators. WebGPU checks secure context, API, adapter and device access, WGSL compilation, a 64 × 64 triangle with pixel readback, and a four-number compute result. WebGL 2 and WebGL 1 each draw a 4 × 4 triangle and verify the center pixel. API exposure or a successful context request is labelled supported; only an executed workload with the expected result is passed. Skipped steps are not-run; unavailable evidence is unknown.
WebGPU adapter.info and WebGL WEBGL_debug_renderer_info remain separate sources. Model information can be hidden. A known software renderer string is evidence of a software path; low FPS or a vendor name alone is not. Working small workloads do not certify hardware health or browser-wide acceleration. Buffer and texture limits are not total VRAM, temperature or clock readings.
Reports use schema version 1 and separate diagnostic and performance kinds. Metric definitions retain legacy-1: existing scores are unchanged. Stress FPS is total rendered frames divided by elapsed seconds; its displayed score is rounded average FPS. Frame-time standard deviation uses the sample variance. P50/P95/P99 use the existing 0.5 ms histogram bins, capped at 200 ms; 1% low FPS is 1,000 divided by P99. The drop ratio is the count of intervals exceeding the target frame budget plus max(1 ms, 8% of that budget) divided by interval count. Stability is round(0.45 × consistency + 0.35 × drop score + 0.20 × spread score). Consistency is clamp(low1Fps / avgFps, 0, 1) × 100, drop score is clamp(1 − drop ratio, 0, 1) × 100, and spread score is clamp(1 − (P95−P50) / (1.5 × target frame budget), 0, 1) × 100.
The legacy stress protocol has no separate warmup window; this is explicitly recorded as zero, rather than claiming a warmed-up benchmark. Shader measures three ten-second scenes at 1280 × 720 and excludes the first three frame intervals per scene. Actual excluded warmup time and remaining measurement time are now recorded. Shader average FPS is 1,000 divided by mean frame time; its 1% low uses the mean of the slowest 1% of retained intervals. Score is 100 times the geometric mean of the three scene FPS values, rounded. Shader stability is the mean of each scene’s low-FPS / average-FPS ratio, clamped to 0–1 and multiplied by 100. Its legacy filter retains intervals between zero and 1,000 ms; a run with excluded abnormal measured intervals is now marked invalid, while the formula stays unchanged.
Stability-page decay compares the mean FPS of the first and last 20% of samples (rounded up): (initial − final) / initial × 100. Stress samples normally arrive every 500 ms plus the final sample. Exported curves use non-overlapping equal-count bucket means of actual seconds and FPS, with at most 120 points. Comparison plots use a shared real-seconds axis, so short runs are never stretched to match long ones.
Hidden pages, context/device loss, failed measurements and cancelled runs cannot count as performance improvements. requestAnimationFrame depends on refresh rate and browser scheduling: a 60 FPS result does not establish full GPU load, and a higher target cannot override display timing. Frame-rate decay describes an observation, not a diagnosis of overheating or power throttling.
At most 20 reports are kept in localStorage in the current browser. This small, bounded history reuses the project’s existing local storage approach; a pinned baseline survives automatic trimming. Auto-save preference and notes persist locally. Storage errors preserve visible results and allow JSON export. The previous Shader result is left untouched and can be explicitly copied into history with unknown validity. Unknown history/schema versions are not overwritten. Clearing history removes unified reports, not the preserved legacy record.
JSON import is limited to 1 MiB, with strict nested field, unit, finite-number and array checks. Reimporting identical IDs is a no-op; conflicting content is rejected. Imports retain their original test time and are labelled external, not rerun or independently verified. Notes and imported text are displayed as text. Copy report and Download JSON contain only the report’s own fields.
Direct performance comparisons require matching test and metric versions, API, workload and measurement configuration, and completed valid runs. Different recorded environments or notes disable percentage comparisons; hardware identity cannot be independently verified. Missing or zero baselines produce no relative change. Ratio changes use percentage points. Diagnostic reports compare checks, features, limits and devices, never performance percentages. Repeat small differences under the same conditions; changes after a driver update or cleaning do not establish causation.