Frametime consistency beats average FPS.

01A frame every n milliseconds

An FPS number is an average over a second. A frametime is the truth underneath it: how many milliseconds each individual frame took. At a perfectly steady 60 fps every frame takes 16.7 ms; at a steady 144 fps, about 6.9 ms.

"Smooth" is not a high average — it's low variance. A game delivering frames at a metronomic 16.7 ms looks fluid. The same game averaging far more FPS but alternating between fast frames and 50 ms hitches looks broken, because motion on screen keeps changing speed.

02Why averages hide stutter

Do the arithmetic on one bad second: 99 frames at ~9 ms plus a single 100 ms hitch is still roughly a "100 fps" second. The counter says everything is fine; your eyes saw the game freeze for a tenth of a second. Repeat that hitch every few seconds — a classic shader-compilation or asset-streaming pattern — and you get a game that benchmarks beautifully and feels terrible.

This is why honest performance talk leads with consistency metrics, and why a frametime graph tells you more than any single number: stutter is visible as spikes that no average can hide.

031% lows, read right

The standard consistency metric is the 1% low: take the slowest 1% of frames in your sample and express their average pace as an FPS-like number. It answers "how bad are the worst moments?" in the same units as the headline number, which makes comparison easy:

• Average 120 / 1% low 90 — worst moments nearly as fast as typical ones. Smooth.
• Average 120 / 1% low 35 — regular, visible hitches. The average is hiding them.

Two reading rules. The metric only stabilizes over a decent sample — judge a few minutes of real play, not a five-second pan. And methodology differs between tools (some quote a percentile frame, some the mean of the worst 1%) — compare numbers only from the same tool.

04Where the spikes come from

• Shader compilation — first encounters with new effects compile code at runtime; the notorious "first playthrough stutter" in DX12/Vulkan titles.
• Asset streaming — textures and geometry loading mid-traversal; worse from slow drives, better but not gone on NVMe.
• CPU contention — a background process stealing time at the wrong moment: updaters, indexing, capture software, browser tabs.
• Clock ramping — power management dropping CPU/GPU clocks in quiet moments, then paying a wake-up cost on the next demanding frame.
• Thermal throttling — clocks sagging under sustained heat, often minutes into a session: starts smooth, degrades as the case warms up.
• Memory pressure — VRAM or RAM overflow forcing mid-frame swapping; the heaviest, most rhythmic stutter of all.

05How to measure honestly

RivaTuner Statistics Server (RTSS) — free, and the measurement backbone of most reviews — draws an on-screen frametime graph and computes 1% lows. The method matters more than the tool:

1. Fix the scene. Same save, same route, same duration. A different fight is a different workload, and comparing them tells you nothing.
2. Change one variable at a time. One setting, one driver, one tweak — then re-run.
3. Watch the graph shape, not just the numbers. A flat band is what "smooth" looks like; recurring spikes at fixed intervals point at a specific subsystem (streaming, background tasks), not general slowness.
4. Let the machine warm up. Thermal behavior only shows after several minutes; a cold two-minute benchmark flatters your cooling.

06Making delivery smoother

• Cap your framerate. A cap a few fps below what your system sustains in heavy scenes converts "fast but erratic" into "slightly slower but metronomic" — usually the single biggest consistency win, and it pairs perfectly with VRR (G-SYNC / FreeSync).
• Trim the background. Fewer processes competing for CPU time means fewer random spikes.
• Keep clocks steady. High-performance power settings reduce ramp-up hitches — at the cost of watts and heat (mind laptops).
• Mind your VRAM budget. If the frametime graph degrades into rhythmic heavy stutter, drop texture quality one notch before touching anything else.
• Let shaders finish compiling. When a game offers a shader pre-compilation step, let it run; the first hour after a driver update will stutter more in titles that don't.