Average frame rate is the number everyone quotes and it is a poor description of how a game actually feels to play. The distribution matters more.
The averaging problem
Sixty frames per second as an average can mean sixty consistent frames, or it can mean long stretches at eighty punctuated by drops to twenty.
Those feel completely different, and the average is identical.
Which is why benchmarking has moved toward percentile figures — the one percent and point one percent lows — which describe the worst frames rather than the typical ones.
A game with a lower average and better lows generally feels smoother than the reverse.
Frame time
The more useful measurement, expressed in milliseconds per frame rather than frames per second.
Sixty frames per second means roughly sixteen and a half milliseconds per frame.
Consistency of that interval is what the eye actually perceives as smoothness.
A frame arriving at eight milliseconds followed by one at twenty-five averages to the same rate and appears as a stutter, because the motion on screen is inconsistent with the timing.
Where stutter comes from
Several distinct causes, which is why it is hard to fix generically.
Shader compilation, where the game builds graphics code the first time a particular effect appears, causing a hitch. Precompiling at startup addresses it and takes time on load.
Asset streaming, where data is loaded from storage as the player moves, which stutters if storage cannot keep up.
Garbage collection in engines using managed memory, which pauses to reclaim memory.
And CPU bottlenecks in specific moments — many entities on screen, physics interactions, complex scripting — which the average frame rate conceals.
Vertical synchronisation
Synchronising frame delivery to the display refresh, which eliminates tearing where two frames appear on screen simultaneously.
The cost is that a frame missing the deadline waits for the next refresh, which halves effective rate rather than reducing it slightly.
Which is why enabling it can turn a fifty-eight frame experience into a thirty frame one.
Variable refresh rate
The solution that actually addressed this.
The display adjusts its refresh interval to match when frames arrive, rather than the other way round.
Which removes both tearing and the waiting penalty, within the display's supported range.
Outside that range — generally below some minimum — the behaviour depends on the implementation, with frame doubling used to stay in range.
It is among the more genuinely significant improvements in display technology for this purpose, and it requires both display and graphics hardware to support a compatible standard.
Latency is separate
Frame rate and input latency are related and not the same thing.
Latency is the time between input and the corresponding change appearing on screen, and it includes input device polling, processing, rendering, and display response.
Deep render queues improve throughput and add latency, which is why features reducing queued frames exist.
Which means a configuration producing higher frame rates can feel less responsive, and competitive players frequently optimise for latency over rate.
What to actually check
Percentile lows rather than averages in any benchmark.
Frame time graphs where available, since a spiky graph indicates problems an average conceals.
And your own experience, since the perceptible threshold varies between people and between game types more than the discourse suggests.
A slow strategy game and a competitive shooter have entirely different requirements, and applying one standard to both wastes money.
Frame generation
A recent technique worth understanding separately from upscaling.
The system generates intermediate frames between rendered ones, using motion data and interpolation, which raises the displayed frame rate.
Which improves perceived smoothness and does not improve latency, because a generated frame contains no new input.
In fact latency increases slightly, since the system must hold a frame to interpolate toward it.
Which makes it well suited to visually demanding single-player games and poorly suited to competitive ones, and marketing that reports the combined frame rate alongside native figures is comparing incomparable things.
Upscaling
Rendering at lower resolution and reconstructing to the output resolution, using temporal information from previous frames.
Which genuinely reduces the rendering cost and can look close to native, and it introduces artefacts in specific situations — fine detail in motion, transparency, rapid camera movement.
Quality varies substantially between implementations and between game integrations, which means the same technique performs differently across titles.
Measuring it yourself
Overlay tools display frame time graphs in real time, which shows immediately whether a stutter is a persistent problem or a one-off.
Logging over a session and examining the distribution afterwards is more informative than watching a counter, and most tools support it.
Background processes
A common and overlooked source of inconsistency.
Update services, overlays, capture software and browser tabs all compete for processor time, and a background task waking during play produces exactly the kind of spike that shows up as a stutter.
Which is worth checking before attributing a problem to hardware.