Timing event detector

Ready
FPS over time · one point per second
Avg FPS —Min FPS —Max FPS —

Live test results

Current FPS— fps
Median baseline— ms
Timing events— events
Worst interval— ms
Average FPS— fps
Test time— seconds
  • No events recorded—

Events are unusually slow intervals relative to the session median—not proof that a frame was dropped.

Ready

Timing spike detection

FPS Drop Test

The FPS drop test flags unusually long browser frame intervals against a robust session baseline and records recent events. It calls them timing spikes because callback data cannot prove a physical frame was dropped.

What Is an FPS Drop Test?

An FPS drop test looks for short periods where observed delivery becomes much slower than its usual cadence. This tool collects browser animation intervals, maintains a median baseline, and flags an interval only when it exceeds both 1.5 times that baseline and a four-millisecond absolute margin. Using two conditions avoids treating tiny high-refresh timestamp variations as meaningful solely because a multiplier was crossed.

The event table lists recent frame indexes and interval durations, while the timeline shows their surrounding context. “Timing event” or “slow frame” is more accurate than guaranteed dropped frame: requestAnimationFrame() timestamps reveal callback spacing but do not expose every stage of display scanout or presentation.

FPS Drops vs Normal Variation

No real scheduling trace is perfectly flat. Timestamp precision, operating-system task switches, rendering work, and refresh cadence produce small variation. A drop worth inspecting stands apart from that local pattern. Median frame time is a useful baseline because a few large intervals do not pull it upward as strongly as a mean. The absolute margin makes detection less hypersensitive when the normal interval is already short.

One event is not automatically a user-visible stutter. Its duration, the cadence around it, display behavior, and motion content all affect perception. Repeated clusters are generally more meaningful than an isolated spike. Use the event count to find candidates, then study the timeline and reproduce the same workload.

How to Get Started

Begin with the page idle so you know the baseline behavior. Start the FPS drop test, wait through warm-up, and keep the tab visible. Next, repeat while performing one browser activity you suspect—such as opening a complex panel on a site you are developing. Do not use this page to claim that an external game dropped frames; capture that game directly.

  1. Run a clean 30-second baseline and note median interval, average FPS, and event count.
  2. Run for approximately the same elapsed time while changing exactly one workload or system setting.
  3. Compare event timestamps and durations, and repeat again before treating a difference as persistent.

How Timing Spikes Are Detected

After at least ten valid intervals, the median becomes the robust baseline. The threshold is the larger of median × 1.5 and median + 4 ms. At a 16.67-millisecond baseline, an interval must exceed about 25 milliseconds. At an 8.33-millisecond baseline, it must exceed 12.5 milliseconds. The same formula is documented on the methodology page and covered by unit tests.

Warm-up intervals are excluded. When the document becomes hidden, the test stops, so time spent in a background tab is not inserted as a normal frame. Starting another test performs a fresh warm-up. Intervals that are non-positive or at least one second are invalid for normal statistics. These guards reduce obvious false events but cannot remove all scheduling noise.

Common Causes of Browser FPS Drops

Long JavaScript tasks, style recalculation, complex layout, image decoding, garbage collection, shader compilation, extension activity, and competing CPU or GPU work can delay browser animation. Video conferencing, screen recording, operating-system overlays, battery saving, and thermal limits may add contention. Moving a window between monitors can briefly disrupt cadence or switch the scheduler’s target display.

The FPS drop test detects the timing symptom, not its source. Developers should correlate an event with a browser Performance profile, long-task data, and application logs. General users can close background work and repeat. If only a native game stutters, use in-game frame-time telemetry and system monitoring because this browser session does not observe that rendering process.

Understanding Stutter and Slow Frames

Stutter describes perceived uneven motion; a slow frame is one timing observation. They overlap, but they are not identical. A static scene may hide a long interval, while smooth camera movement can make a smaller cadence disruption obvious. Screen tearing is different again: it occurs when portions of multiple frames appear in one scan, and it is better inspected with the screen tearing pattern.

Frame time is the clearest unit for an event because it preserves duration. Equivalent FPS can exaggerate small short intervals and compress long ones through the reciprocal relationship. A 16.67 ms interval corresponds to 60 FPS, 25 ms to 40 FPS, and 50 ms to 20 FPS. Read the actual milliseconds when comparing spike severity.

Useful Scenarios and Limitations

This frame spike test helps investigate intermittent web animation, compare browser configurations, validate whether a performance optimization reduces long intervals, or demonstrate why averages miss short disruptions. It is most useful with repeated, controlled steps and a longer sample when events are rare. Copy results so durations and counts are not remembered loosely.

The test cannot prove a dropped presentation, identify defective hardware, inspect external applications, or guarantee that a detected event was visible. Browser version, OS scheduling, display selection, power mode, variable refresh, and system load influence the capture. The threshold is a documented heuristic, not a universal stutter boundary. Use it as a consistent flag for investigation rather than a pass/fail certification.