How this page works & what everything does

Background Loop

A requestAnimationFrame loop runs continuously to measure frame timing. Each frame, the loop records the elapsed time since the last frame, appends it to a rolling 120-sample buffer, and redraws the frame-time graph on a <canvas> element. This loop itself is intentionally lightweight — all frame budget consumption comes from the stress modules below.

Stats Bar (top-right)

Frame Time Graph

The canvas graph plots the last 120 frame durations as a bar chart. Bars are color-coded: green = normal (<16ms), amber = degraded (16–50ms), red = severe jank (>50ms). A dashed line marks the 16.67ms target threshold.

Master Intensity (slider)

A global multiplier (1× – 20×) applied on top of each individual stressor's settings. At 20×, the burn duration, DOM element count, allocation size, timer count, and microtask depth are all scaled up by 20. Use this to quickly ramp all active stressors simultaneously without adjusting each card.

☢ NUKE Button

Temporarily overrides every stressor to its absolute maximum value and enables all of them for 5 seconds, then restores all previous states. Use this to instantly simulate a worst-case scenario and observe how the browser (and any monitoring tools you're testing) responds.

↺ RESET ALL Button

Disables every stressor, resets all sliders to their default values, clears the held memory buffer, and clears the frame-time graph. Returns the page to a clean baseline state.

Stress Modules

🔥 CPU Burn Loop

What it does in the background: a setInterval fires every Interval ms. When it fires, it runs a synchronous while loop for exactly Burn duration ms (measured via performance.now()), performing floating-point math (Math.sin, Math.cos, Math.sqrt) and string concatenation to prevent the JIT from optimizing it away. This is the most direct way to starve the event loop — nothing else can run during the burn.

🌪 DOM Thrash

What it does in the background: inside every requestAnimationFrame callback, it creates N <div> elements in an off-screen container, then reads their offsetHeight (forcing a synchronous layout reflow), then mutates their style.width (invalidating layout again). This read-write-read pattern prevents the browser from batching style recalculations and layout. After processing all elements, they are removed. High element counts can spike frame time into the hundreds of milliseconds.

💾 Memory Pressure

What it does in the background: a setInterval allocates a Float64Array of the configured size. In hold mode the reference is pushed into a retained array, growing the JS heap until the tab is killed or the stressor is reset. In release mode the reference is immediately discarded, triggering frequent garbage collection cycles which pause JS execution (GC pauses can be 5–50ms depending on heap size).

⏱ Timer Flood

What it does in the background: every Interval ms, it schedules N setTimeout(fn, 0) calls simultaneously. Each callback sorts a small random array, does a string join, and runs a short math loop — lightweight per-task but collectively overwhelming. This exercises the browser's task scheduler and timer queue, which can cause starvation of other event listeners and I/O callbacks.

⚡ Microtask Storm

What it does in the background: every Interval ms, it kicks off a chain of N resolved Promise.resolve().then() calls, each scheduling the next. Crucially, the microtask queue is drained completely before the browser returns to the task queue — so a chain of 100,000 microtasks blocks rendering for the entire duration of the drain, with no opportunity for the browser to paint frames or handle input. Unlike timers, you cannot "yield" out of a microtask chain once it starts.