The counter in the corner says 90. The game just lurched, you lost the corner, and the counter still says 90. Nothing is wrong with the counter — it is answering a question you did not ask.
Average frames per second is an arithmetic mean, and a mean is designed to absorb outliers. Stutter is the outlier. So the number that describes your experience worst is exactly the number every box, every settings menu and half of every review leads with.
What one hitch costs the average
Take a minute of play at a steady 60 fps: 3600 frames, each arriving 16.7 ms apart. Now let one of them take 100 ms — a hitch you will not only notice but complain about.
The minute now takes 60.08 seconds instead of 60. The average comes out at 59.9 fps.
That is the whole indictment. A hitch bad enough to lose you a fight moves the headline number by less than a tenth of a frame per second, which is inside the noise between two runs of the same benchmark. Run it the other way and it is worse: 59 frames at 15 ms and one at 100 ms still total 985 ms, so a second containing a visible lurch reports 61 fps — better than your target.
The average is not lying. It is averaging. You wanted to know about the worst frames, and you asked for the mean of all of them.
What the percentile numbers actually count
The fix reviewers settled on is percentiles, usually written as 1% low and 0.1% low. The wording is unfortunate, because it sounds like a footnote about rare events. It is not.
A 1% low is the 99th percentile of frametimes — sort every frame by how long it took, walk to the slowest one per cent, and report from there. Over that same 60-second run of 3600 frames, one per cent is 36 frames. If those frames are averaging 40 ms, they account for about 1.4 seconds of your minute.
A second and a half of visible roughness per minute is not a tail event. It is the thing you would describe to a friend if they asked how the game runs. And the 0.1% low — 3 or 4 frames out of the 3600 — is where the genuinely ugly hitches live, the ones that survive in memory long after the session.
It is worth knowing what these replaced. Reviews used to print a minimum framerate, and minimum framerate is a single frame — the worst one in the run. One frame is a coin toss: a background process, a shader compiling, an autosave. Run the same benchmark three times and the minimum moves by twenty per cent while nothing about the machine changed. A percentile is the same idea made repeatable, which is the only reason the numbers in a modern review can be compared at all.
So the two numbers answer different questions. The average answers "how much work did the machine get through". The percentiles answer "how evenly did it arrive". Only the second one is what smoothness means.
What the average is actually for
None of this makes the mean a bad number. It makes it a number with a job, and the job is not smoothness.
The average answers capacity: how much work the machine got through in the time it had. That is exactly the right question when you are deciding whether a card can run a title at a resolution at all, when you are comparing two generations of silicon, or when you are working out what a settings preset costs you. For those, the mean is the correct instrument and the percentiles are the distraction — a card that renders 30 per cent more frames renders 30 per cent more frames, and you want that stated plainly.
The mistake is not printing it. The mistake is reading it as a description of how the game will feel, which it was never able to be. A frame counter measures throughput, and smoothness is a property of the intervals between arrivals. They are different measurements of the same stream, and a machine can be excellent at one and poor at the other.
Which is why the practical answer is never "ignore the average". It is: read the average to find out what you can run, and read the distribution to find out what it will be like.
Four spikes, and how to tell them apart
Spikes are not one fault. They have shapes, and the shape names the cause.
Shader compilation
Dense clusters of spikes in the first minutes of a level, on first encounters with an effect, and never again on a second run through the same area. Modern APIs hand the driver the job of turning shaders into machine code, and it happens when the effect is first needed unless the game precompiled. Signature: it goes away on the repeat run, and it comes back after a driver update wipes the cache.
Asset streaming and traversal
Regular spikes tied to movement, not to action — crossing a boundary, turning a corner into a new district, a fast vehicle. The engine is pulling assets while it renders. Signature: reproducible at a place rather than at a moment, and sensitive to the drive the game sits on.
VRAM overflow
The nastiest one to diagnose, because the average barely moves. Once the working set does not fit in video memory, the card starts fetching over PCIe, and the cost lands on isolated frames rather than on all of them. Signature: raise texture quality one notch and the average stays roughly put while the 1% low falls through the floor. The 8 GB and 16 GB versions of otherwise identical cards are the cleanest demonstration on the market — same core, same clocks, and at 1440p the larger buffer has been measured returning 1% lows a quarter to a third higher while average framerates sit close together.
The CPU running out of thread
Periodic spikes that scale with what is happening rather than where you are: a physics event, an autosave, a crowd, a shader-heavy alt-tab. Signature: dropping the resolution does not help, because the frames are not being held up by the card.
Measuring it on your own machine
Everything worth using traces back to one capture layer. Intel's PresentMon reads the frame-presentation events the operating system already emits, and CapFrameX, NVIDIA's FrameView and AMD's OCAT are all built on top of it. Which one you run is a matter of taste; what they capture is the same event stream.
Two rules make the capture worth having. Capture a real scene rather than a built-in benchmark — built-in benchmarks are chosen by the developer to be reproducible, which usually means they avoid the streaming and traversal that produce the spikes you are hunting. And capture at least 60 seconds, because a 1% low over a ten-second run is three frames, and three frames is an anecdote.
Then look at the graph before you look at any number. A wall of small ripples, a few tall isolated spires and one cluster at the start are three different problems, and no single figure distinguishes them.
The one ratio worth carrying
If you want a single number to hold in your head while reading reviews, divide the 1% low by the average.
- Above about 0.6 — the frames are arriving evenly; the average describes what you will feel.
- Between 0.5 and 0.6 — noticeable roughness under load, usually acceptable.
- Below about 0.5 — the average is describing a machine you are not playing on.
That ratio is ours and it is a rule of thumb, not a measurement: it is what the two published numbers imply about the distribution between them, and it will mislead on a title with one giant hitch and otherwise perfect pacing. Use it to decide which review to read closely, not to settle an argument.
What makes it useful is that it survives the comparison the average cannot. Two cards within a couple of per cent on average framerate, one at 0.68 and one at 0.44, are not two similar cards.
A faster panel shows you more of this, not less
There is an unwelcome consequence of upgrading the display, and it catches people who bought the monitor precisely to smooth things out.
A screen refreshes on a fixed interval. At 60 Hz that interval is 16.7 ms; at 144 Hz it is 6.9 ms; at 240 Hz it is 4.2 ms. A frame that arrives a few milliseconds late has to wait for the next refresh, and how much of a stumble that is depends entirely on how long the wait is relative to everything around it.
Put a 6 ms wobble into both. On the 60 Hz panel it disappears inside the interval — the frame still lands on the same refresh it would have. On the 240 Hz panel it is more than one whole refresh of delay, and the eye reads it as a stumble in an otherwise very smooth stream. Same machine, same wobble, two different experiences, and the faster panel is the one that shows it.
Variable refresh changes the arithmetic rather than removing it: the display waits for the frame instead of the frame waiting for the display, which genuinely removes judder and tearing in the range where it operates. What it cannot do is invent a frame that has not been rendered. A 100 ms gap is 100 ms of the same image on screen at any refresh rate, adaptive or not.
The honest reading is that a high-refresh panel raises the ceiling on how good even delivery can look, and simultaneously raises your sensitivity to uneven delivery. It is an upgrade for a machine whose frames already arrive evenly, not a treatment for one whose frames do not.
What to change, and what not to buy
The upgrade that fixes stutter depends entirely on which spike you have, and this is where the money usually goes wrong.
- Shader-compilation clusters: nothing you buy fixes this. Let the game run its precompile step if it offers one, and expect the first hour after a driver update to be rough. A faster card compiles no less often.
- Streaming and traversal: the drive matters here and almost nowhere else in gaming. This is the one symptom for which an NVMe upgrade is the correct answer.
- VRAM overflow: capacity, not speed. A faster core with the same buffer changes nothing about the wall you are hitting — and dropping texture quality one notch is free and works today.
- CPU-bound spikes: the processor, and no amount of graphics card. Lowering the resolution is the diagnostic: if the spikes survive it, the card is not the constraint.
Two things we would not buy to fix stutter
A faster graphics card, until you know which of the four you have. Three of them are unmoved by it, and the fourth wants capacity rather than speed. This is the most expensive wrong answer available in this shop, and we would rather sell you the right part twice than the wrong part once.
And a higher-refresh monitor. A 240 Hz panel shortens the interval between frames that arrive on time; it does nothing whatsoever to a frame that arrives 100 ms late. Variable refresh is worth having and it smooths judder — but a hitch is not judder, and no display technology invents the missing frame.
How this was put together
The percentile practice and the tooling come from the people who publish frametime data rather than bar charts: Digital Foundry's frametime traces, Gamers Nexus's 0.1% lows, Hardware Unboxed's and TechSpot's 1% lows across paired 8 GB and 16 GB cards, TechPowerUp's per-title runs, and Intel's PresentMon, which is the capture layer under CapFrameX, FrameView and OCAT alike.
The derived figures are ours: the 100 ms hitch that costs 0.1 fps in a 60-second average, the same hitch reporting 61 fps inside its own second, the 36 frames that a 1% low actually counts over that run, and the 1%-low-to-average ratio with its 0.6 and 0.5 marks.
