Frame-Time Monitor: Jank & FPS Percentiles

Frame Budget

Target refresh rate

Workload

Base render cost 9 ms

Frame-time jitter 3 ms

Simulate periodic GC pauses (+60–120 ms stalls)

Live Telemetry

Current FPS

60.0

Jank rate

p95 frame time (last 90 frames)

0.0 ms

On budget (< 80% of budget) Tight (80–100% of budget) Janky frame (over budget)

How it works

A mobile APM's frame-time monitor samples one number per rendered frame — the wall-clock time the UI thread spent producing it — and derives everything else from that rolling window:

frame_budget_ms = 1000 / target_fps
jank(frame)     = frame_time_ms > frame_budget_ms
jank_rate       = janky_frames / window_size
fps_instant     = 1000 / frame_time_ms
p95             = 95th percentile of the last N frame times (sorted)

This simulator generates a synthetic frame-time stream the same way a real device does: a base render cost (layout + paint + GPU composite) plus random jitter from scheduling noise, with an optional garbage-collector pause — a large, infrequent spike that stalls the UI thread for tens of milliseconds. Each bar in the 3D chart is one frame; height and color both encode its time, and the translucent plane marks the current frame budget. Cross the plane and the frame counts as jank exactly the way Firebase Performance, New Relic or a custom APM's frame-metrics pipeline would flag it — this is the same threshold-crossing model used to compute the "smooth scroll %" and jank-rate dashboards real mobile teams watch in production.

Target refresh rate — sets the budget line: 60 FPS gives every frame 16.7 ms to finish.
Base render cost / jitter — the mean and spread of the simulated per-frame UI-thread work.
GC pauses — toggles occasional large stalls, the classic cause of a "janky" scroll on managed-memory runtimes (Android ART, JS engines).

Frames sampled: 0Worst frame: 0.0 ms

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.