Frame Rate Test

A frame rate test measures how many images a device delivers per second, and how evenly those images arrive. This test samples the timestamp the browser attaches to every animation frame and converts the interval between consecutive frames into a frame rate in FPS. From those samples it reports six figures: the live counter, the average, the minimum, the 1% low, the standard deviation of frame intervals, and a stutter count. The average describes throughput while the other five describe consistency, which is why they are reported separately. A single average number cannot tell you whether a run was smooth or full of hitches.

Make sure this tab is the active window, because browsers throttle animation frames in background tabs and the reading will collapse to a token rate. Close heavy applications, click Start Test, and leave the counter running for at least ten seconds, at which point the run completes automatically and the diagnostic panel scores it. Watch the average settle first, then compare it against the 1% low directly underneath, and read the frame-time jitter and stutter count last. For a fair comparison, run the test three times under identical conditions and compare the spread rather than trusting one reading, since a single run is easily skewed by a background update.

The 1% low takes the slowest one percent of frames in a run, averages their frame times, and converts that back into a frame rate. It answers the question the average cannot: how bad are the bad moments? If the average is 120 FPS but the 1% low is 45 FPS, then about one frame in a hundred takes more than three times as long as it should, and those stalls are exactly what players perceive as hitching and missed inputs. As a practical rule, a healthy system keeps the 1% low within roughly 10 to 20 percent of its average, and any wider gap points at a pacing problem rather than a raw speed problem.

For desktop work, video, and browsing, 60 FPS is comfortably smooth because it matches the refresh rate of most displays. For gaming, 60 FPS is playable, 120 FPS gives a clear improvement in motion clarity and input response, and 240 FPS mainly benefits competitive players who also have a matching high refresh rate panel. Above your panel refresh rate, extra frames are largely discarded, so a 90 FPS result on a 60Hz screen mostly adds smoothness through reduced tearing rather than through visible extra frames. Consistency matters more than the peak, and a locked 60 with a 1% low of 55 feels better than an average of 90 with a 1% low of 30.

Stutter almost always comes from uneven frame times rather than from an insufficient average. The most common cause is background load: a second monitor playing video, a browser tab decoding a large page, a cloud sync client, or a system update all steal CPU and GPU time in bursts. The second common cause is thermal or power management, since laptops on battery and thin chassis under sustained load reduce clocks, which is why a run often starts fast and degrades within a minute. The third is a frame rate cap combined with a mismatched refresh rate, where VSync and a 60 FPS cap on a 60Hz panel fight each other and produce visible judder.

It is accurate for what it measures, which is the frame rate the browser rendering pipeline actually delivers to the screen, and it is the correct tool for a web application, a browser game, or a canvas and WebGL scene. Every frame is timestamped by the browser itself, so the intervals are real and not estimated. The limits are scope rather than precision: the browser cannot read the internal FPS counter of a native game in another window, cannot report GPU utilisation or clock speed, and cannot measure click-to-photon latency. It also cannot be a bare-metal benchmark, because the operating system and the browser both add their own load.

They measure two different things that are easy to confuse. A refresh rate test measures the panel ceiling: how many times per second the display can physically redraw, typically 60, 120, 144, or 240 times, and it also checks for ghosting and frame skipping. A frame rate test measures what is actually being delivered into that ceiling. The relationship matters: if your panel is 144Hz but the delivered frame rate is 60, the display is not the bottleneck at all and upgrading it would change nothing. Run the refresh rate test to establish the ceiling, then run the frame rate test to see how much of that ceiling you are actually using.

Work through the causes in order of likelihood. First close other tabs, video calls, and launchers, then rerun the test to see how much of the drop was background load. Second, check CPU and GPU utilisation during the run, because a single pinned core or a busy graphics queue normally explains a low 1% low. Third, switch the operating system power profile from a saving mode to balanced or high performance, which matters most on laptops running on battery. Fourth, update the graphics driver and confirm that a hybrid graphics laptop is using the discrete GPU. Finally, reduce the rendering load of the page you are measuring.

You can test any game that runs inside the browser tab, including HTML5, canvas, WebGL, and WebGPU titles, because those are drawn through the same animation frame pipeline this test samples. You cannot test a native game running in another window or in fullscreen exclusive mode, because a web page has no access to another application internals. For native games, use the built-in FPS overlay of the game or the graphics driver, for example the performance overlay in NVIDIA GeForce Experience or AMD Adrenalin. Use this test for browser games and web applications, and use those overlays when you need in-game telemetry.

Frame time is how long a single frame takes, measured in milliseconds, while FPS counts how many frames fit into one second. The two are mathematical inverses: 60 FPS equals 16.7 ms per frame, 120 FPS equals 8.3 ms, and 144 FPS equals 6.9 ms. Frame time is the more revealing figure when you are chasing stutter, because it describes each frame on its own instead of averaging a whole second of them. A run that averages 60 FPS can still contain individual frames of 40 ms or worse, and those long frames are exactly what the eye reads as a hitch. This test reports frame time directly so the outliers that a plain counter hides become visible.

A high average with unstable frame times feels worse than a lower but steady one, because the eye is far more sensitive to changes in pacing than to absolute speed. If a run averages 144 FPS but every tenth frame takes 30 ms, motion will visibly judder despite the healthy average. Typical causes are one CPU thread saturating, a shader compilation stall, a texture streaming hitch, or a background process competing for the GPU. The practical check is to watch the 1% low and the stutter count rather than the average: a 1% low within 10 to 20 percent of the average means pacing is healthy, and a wider gap means the bottleneck is a spike rather than raw performance.

A frame rate cap limits how many frames the application is allowed to produce, usually to keep the output aligned with the display. Capping slightly below the panel refresh rate, for example 141 FPS on a 144Hz screen with VSync enabled, is the standard way to cut input latency while avoiding tearing. On a variable refresh display such as G-Sync or FreeSync, a cap below the maximum refresh keeps the panel inside its variable range and stops it dropping back to fixed-rate behaviour. A cap only becomes harmful when it is set below what the system could otherwise deliver for no good reason, because it then leaves real performance unused.