Skip to main
Table of Contents

Stress Test

This page demonstrates browser-based CPU and GPU stress patterns using Web Workers and an offscreen WebGL render loop. It is intended for controlled testing and educational use, not precise system benchmarking.

Caution: This demo can make your browser or device unresponsive. Start with a short auto-stop duration and use native system tools (Task Manager, Activity Monitor, etc.) for real usage metrics.

Stress Test Controls

Choose test options, start CPU, GPU, or both, and monitor the runtime status below. The demo reports capabilities and state, but does not provide real-time CPU/GPU utilization percentages.





Status: Idle.

Capability: Checking browser support...

Runtime: 00:00 (auto-stop in 10s)

Current State

  • CPU RunningNo
  • GPU RunningNo
  • Active CPU Workers0
  • Elapsed00:00

Browser Support

  • Web WorkersUnknown
  • Blob Worker URLUnknown
  • OffscreenCanvasUnknown
  • WebGL (worker path)Unknown

Notes

  • CPU mode uses busy-loop workers.
  • GPU mode runs a Worker + OffscreenCanvas WebGL draw loop.
  • Some browsers may support CPU stress but not GPU worker rendering.
  • Use Stop All if a mode becomes unresponsive.

Code for This Render

The page binds button events in JavaScript, starts worker-based CPU and GPU loops, updates status text, and supports a configurable auto-stop timer.

<input id="stress-cpu-workers" type="number">
<select id="stress-gpu-canvas-size">...</select>
<button id="stress-cpu-button">Start CPU Stress Test</button>
<button id="stress-gpu-button">Start GPU Stress Test</button>
<button id="stress-both-button">Start CPU + GPU Stress Test</button>
<button id="stress-stop-all-button">Stop All</button>
// asset/js/content/example/stress-test.js
// - detect worker / OffscreenCanvas / WebGL support
// - spawn N CPU busy-loop workers
// - start/stop GPU worker draw loop
// - update status + runtime + support fields
// - auto-stop after configured duration (optional)

Why Real-time CPU / GPU Usage Is Not Available

Web pages do not receive direct access to native system usage metrics. Browsers intentionally sandbox web apps and expose only limited performance APIs.

  • Security and privacy: fine-grained hardware telemetry could expose sensitive system details.
  • Sandboxing: browsers prevent direct access to system-level monitoring interfaces.
  • API limitations: there is no standard browser API for real-time CPU/GPU utilization percentages.
  • Measurement bias: in-page monitoring would itself consume resources and distort results.

Files for This Page

  • Page HTML: in/example/stress-test.html
  • Page SCSS: in/asset/css/content/example/stress-test.scss
  • Page JS: in/asset/js/content/example/stress-test.js

Attribution