Frame Sampling and Warm-Up
Frame-related tools use window.requestAnimationFrame() and the callback timestamp supplied by the browser. Consecutive timestamps are subtracted to create raw frame intervals in milliseconds. The page does not count callback invocations inside a one-second bucket and then label that integer as the only result; interval sampling preserves timing distribution and supports mathematically consistent statistics.
Each new run begins with a 1.2-second warm-up. Callbacks during warm-up are not included in reported results. Initialization, canvas allocation, code compilation, and the first scheduling transition can otherwise distort a short sample. Starting again after stopping or hiding the page performs a fresh warm-up and begins a new result set.
Visibility and Valid Sample Filtering
Browsers reduce or stop animation callbacks for hidden documents. FPS Tester listens for visibilitychange and stops an active FPS-series test as soon as the document becomes hidden. The page does not insert the time spent in another tab as an FPS drop or timing spike. The user starts a new run, which performs another warm-up before valid collection continues.
Statistical functions accept only finite intervals greater than zero. The live sampler also rejects intervals at or above one second as invalid for ordinary frame statistics. That upper guard is separate from hidden-tab handling and prevents an extraordinary suspension from dominating arrays. It is not used to erase ordinary slow frames: intervals below one second remain eligible for tail and spike analysis.
One-Second Chart and Stress Workload
FPS-series charts group valid frame intervals into approximately one-second buckets. FPS views plot three connected series for each elapsed second: average FPS uses 1000 / mean bucket interval, minimum FPS uses the longest interval, and maximum FPS uses the shortest interval. Frame-time views plot the mean interval in milliseconds. Detailed result cards continue to use the complete retained interval sample.
Stress Level controls a local canvas workload from zero to 1,400 animated elements. The animation appears only during an active test and changes immediately when the slider moves. It is intended to create a repeatable browser-side rendering condition for comparison; it is not a native GPU benchmark, a hardware rating, or a substitute for application-specific profiling.
Average, Median, Variance, and Percentiles
Mean frame time is the arithmetic mean of valid millisecond intervals. Average FPS is 1000 / mean frame time; FPS Tester does not average rounded instantaneous FPS values. Median uses the center of a numerically sorted set, averaging the two central values for an even-sized set. Minimum and maximum frame time come directly from valid samples, while equivalent minimum FPS uses the longest interval and maximum FPS uses the shortest.
Variance is the population mean of squared differences from mean interval, and standard deviation is its square root. The coefficient of variation is standard deviation divided by mean interval, expressed as a percentage. Percentiles use linear interpolation at (n − 1) × q in the sorted set. P95, P99, and—when at least 1,000 intervals exist—P99.9 describe the slow side because larger frame time is worse.
1% Low and 0.1% Low FPS
For 1% low, valid frame intervals are sorted from longest to shortest. The tool takes ceil(n × 0.01) intervals, calculates their mean, and converts that mean to equivalent FPS. At least 100 intervals are required. For 0.1% low, the fraction is 0.001 and at least 1,000 intervals are required. Until those thresholds are met, the interface states that samples are insufficient.
This definition is consistent throughout FPS Tester but is not the only convention used by native benchmark tools. Some software averages instantaneous FPS, uses a percentile cutoff, or processes presentation events differently. Comparisons must use the same method and source. Browser-observed lows cannot be substituted for a game’s own capture because this page has no access to that process.
Jitter, Stability Score, and Timing Spikes
Jitter is median absolute deviation: calculate the median interval, find each interval’s absolute distance from it, then take the median of those distances. The stability score is 100 × exp(-8 × relative MAD), clamped to 0–100, where relative MAD is jitter divided by median interval. This makes the score sensitive to consistency rather than absolute rate. Stable 60 FPS is not penalized solely for being slower than stable 144 FPS.
A timing spike is any valid interval above both median × 1.5 and median + 4 ms, once at least ten intervals exist. The threshold uses a robust median baseline plus an absolute guard for high-refresh noise. The label is intentionally “timing spike,” “slow frame,” or “irregular interval.” A callback gap is not conclusive proof that a physical presentation was dropped.
The frame pacing test also reports the share of intervals within ±10 percent of the median. Its alternation heuristic ignores deviations smaller than the greater of 0.5 ms or 5 percent, then measures how often meaningful above-median and below-median signs switch. At least six meaningful deviations are required. “Possible” and “strong pattern” describe this session’s cadence shape; they do not diagnose a fault.
Refresh Cadence Estimation
Refresh-rate estimation requires at least 120 valid frame intervals. The sorted set is trimmed by ten percent at both ends, the median remaining interval is converted to hertz, and the result is compared with a maintained list of common standards. Fractional 59.94 is listed separately from 60; a cadence near 119.88 will normally match 120 within the expected tolerance.
The refresh chart plots instantaneous browser callback hertz against a labeled five-second time axis, while the large translucent value shows the latest rate. The Refresh rate result remains the robust trimmed estimate rather than one instantaneous point. Confidence describes relative distance to the nearest standard: at most 0.8 percent is high, at most 2.5 percent is medium, and a larger difference is low. It does not certify hardware. Browser scheduling, multiple monitors, dynamic or variable refresh, power management, recording, and system load can make callback cadence disagree with the configured or physical rate.
Mouse Event and Reaction Timing
The mouse tool stores timestamps from pointer movement and uses coalesced sub-events when the browser supplies them. Positive intervals below 250 ms are converted to event rates. Estimated rate is the reciprocal of median event interval; average rate is the mean of individual reciprocals, and peak is the maximum. At most 5,000 timestamps are retained. These are browser-received events, not direct USB controller reports.
The reaction tool waits a random 1.4–4 seconds, applies the visible ready state, stores performance.now(), and ends on pointer or keyboard activation. Early input is a false start and is excluded. Five valid rounds report arithmetic mean, median, minimum, and population standard deviation. The measurement includes display, browser, input device, operating system, and human response.
Precision, Reproducibility, and Boundaries
Calculations retain JavaScript numeric precision and round only for display—usually one decimal for FPS and two for frame time. Canvas charts cap device pixel ratio at two and update in batches, reducing the chance that the visualizer itself adds heavy per-frame work. Continuous tools retain bounded arrays. Event listeners, observers, and animation loops naturally end on page navigation in this static multi-page application.
For reproducible tests, use the same current browser, display, window position, duration, power mode, and background workload. Keep the tab visible, run at least three samples, and change one variable at a time. Results are observational and informational: they cannot certify a monitor, GPU, mouse, neurological response, or external game. Source calculations are unit-tested so the documentation and production logic remain aligned.