\ 1% Low FPS Explained: Why Average FPS Can Hide Stutter

1% Lows Explained: Why Average FPS Can Hide Stutter

A game can average 120 FPS and still feel rough. 1% lows help expose the slow frames hidden by the average, but the metric needs careful testing to be useful.

People playing PC games on desktop monitors at a gaming event
Image: Daniel Benavides / Wikimedia Commons — CC BY 2.0 · source ↗

A benchmark can say 120 FPS and still describe a game that feels rough. That is the reason performance overlays increasingly show 1% low FPS alongside the average. Average frame rate tells you how much work the system completed overall; low-percentile metrics tell you more about the slow frames hiding inside that average.

The number is useful, but it is also easy to misuse. Different tools can calculate percentile statistics differently, and a single bad loading hitch can distort a short capture. Treat 1% lows as a diagnostic summary, not as a magical score that replaces a frame-time graph.

Why average FPS can hide stutter

Imagine a game that renders most frames very quickly but occasionally pauses while loading assets or compiling a shader. The fast frames can keep the average high even though the pauses are obvious to the player.

Frame time makes this easier to understand. At 60 FPS, a frame budget is about 16.7 milliseconds. At 120 FPS it is about 8.3 ms. If most frames arrive around 8 ms but a group of them take 30, 50 or 100 ms, the average FPS may still look respectable while motion feels uneven.

What “1% low” is trying to show

In practical benchmarking, 1% low is intended to summarize the slow end of the run rather than the typical frame. NVIDIA now exposes FPS 1% Low in its performance overlay, and tools built around PresentMon also report percentile performance.

The exact implementation matters. Percentile FPS and percentile frame time are not interchangeable labels, and tools can choose different sampling or aggregation methods. That is why you should compare results from the same tool and methodology instead of mixing a 1% low from one benchmark with a figure from another.

1% low is not the lowest frame

This is one of the most important distinctions. A 1% low metric is designed to describe a group of slow frames, not the single worst frame in the entire capture. The absolute worst frame might be a one-off event such as opening a menu, a background task waking up or the game crossing a loading boundary.

That makes a percentile more representative than “minimum FPS,” but it does not make it immune to bad test design. If the capture is only 20 seconds long and includes a loading screen, the low end can still be dominated by something that is not part of normal gameplay.

Why two PCs with the same average can feel different

Suppose PC A averages 100 FPS with a 1% low around 80, while PC B also averages 100 FPS but repeatedly drops into much slower frames. The headline average is identical, but PC A will generally feel more consistent.

This is why low-percentile performance is valuable when comparing CPUs, memory configurations and games with heavy asset streaming. A faster average does not always mean the better experience if it comes with worse pacing.

Frame-time graphs still tell you more

A single 1% low number cannot tell you why the slow frames happened or how they were distributed. Ten medium-sized spikes and one giant hitch can produce similar summary statistics while feeling different.

When troubleshooting, look at the frame-time graph. Regular spikes can point toward periodic background activity. Spikes that occur only on first traversal of an area may suggest shader compilation or asset streaming. A broad rise in frame time during a crowded scene may simply mean the CPU or GPU has become the performance limit.

How to benchmark 1% lows without fooling yourself

Use a repeatable test. Keep the same game version, resolution, graphics preset, driver and background software. Capture the same built-in benchmark or the same route through the game for long enough that one accidental hitch does not dominate the result.

  • Run the test more than once.
  • Ignore obvious loading screens unless loading is what you are measuring.
  • Keep overlays and recording software consistent between runs.
  • Let shader compilation finish when the game clearly performs it on first launch.
  • Compare the same metric from the same tool.

If results jump wildly between runs, the variance itself is useful information. Do not average unstable captures into a precise-looking conclusion.

What counts as a “good” 1% low?

There is no universal ratio that every game must meet. A competitive shooter with a locked high refresh target has different expectations from a simulation that occasionally streams huge world chunks. Frame-generation techniques also complicate comparisons because displayed frame rate, rendered frame rate and latency do not describe the same thing.

Instead of chasing one percentage, ask whether the lows are close enough to the average that motion remains consistent for the type of game you are playing. If a 144 FPS average comes with repeated drops that you can feel, the low-percentile result is telling you something worth investigating.

Use averages and lows together

Average FPS still matters. It tells you overall throughput and remains useful for comparing broad performance. The mistake is treating it as the whole experience.

A good benchmark report includes average FPS, a low-percentile metric and, when possible, frame-time data. Together they answer three different questions: how fast the game usually runs, how bad the slower frames are, and whether those slow frames happen as isolated spikes or as a persistent pattern.

Use the number to explain the experience

1% low FPS exists because games are experienced one frame at a time, not as an average. It can expose instability that a headline FPS figure hides, especially when stutter is the problem you are trying to understand.

Just keep the number in context. Use consistent tools, repeatable captures and frame-time graphs when diagnosing a real issue. A benchmark becomes more useful when it explains the experience—not when it adds another number to chase.