Frames per second is the metric everyone quotes and the one that explains the least. It is a mean, reported without a distribution, describing a process whose failure mode lives entirely in the tail.
Anyone who has worked on latency-sensitive systems will find the pattern familiar. The interesting analysis is not in the average — it is in what happens during the worst one per cent of events, because that is what the user actually notices.
Why the average misleads
Consider two systems, both averaging 200 frames per second over a sixty-second sample.
The first delivers frames at a consistent five-millisecond interval throughout. The second alternates between very fast frames and occasional frames taking forty milliseconds or more. Identical means. Completely different experiences.
The second is visibly worse, and not marginally. The eye is extremely sensitive to irregular motion — considerably more sensitive to variance in timing than to the absolute rate. A system that stutters intermittently reads as broken even when its headline number is excellent.
This is why the useful unit of analysis is frame time in milliseconds rather than frames per second. Frame time is the underlying measurement, it is additive, and it can be analysed as a distribution. Frames per second is its reciprocal, aggregated, and reciprocals of averages are treacherous things to reason about.
Percentiles are the correct summary
The convention that has emerged among people who measure this properly is to report percentiles of frame time rather than a mean.
The 50th percentile describes typical performance. The 99th percentile — commonly reported inverted as the “one per cent low” — describes the worst one in a hundred frames. The 99.9th captures rarer, more severe events.
The gap between the median and the 99th percentile is the number that predicts perceived quality. A tight distribution feels smooth. A wide one feels unstable regardless of where the centre sits.
This will be recognisable to anyone who has done service-level analysis on request latency. It is the same statistical problem: an average response time that looks healthy while a meaningful fraction of users experience something considerably worse.
Decomposing the latency chain
Frame time is only one component of what a player actually experiences. The full path from physical input to visible response includes several stages.
Input device polling introduces a delay determined by its sampling rate. The operating system adds queueing. The game engine processes the input in its next simulation step. Rendering follows. The display driver queues the completed frame. The monitor then draws it according to its own refresh cycle.
Total latency is the sum, and each stage contributes differently. Some are fixed by hardware, some are configurable, and some can be eliminated by removing intermediate buffering. Practical writeups on CS2 performance optimization essentially work through this chain stage by stage, which is a more coherent framework than the usual advice to lower settings until it improves.
The analytical point is that optimising one stage while ignoring the rest yields poor returns. A pipeline is bounded by its slowest component, and the largest contributor is frequently not the one being measured.
Measurement has to be honest
A few methodological problems appear repeatedly in this space and are worth naming.
Benchmark scenes are rarely representative. A scripted sequence tests something quite different from a chaotic moment with multiple entities, effects and audio sources active simultaneously — which is precisely when performance matters and precisely when it degrades.
Sample duration is often too short. Thermal behaviour changes performance over minutes, not seconds, and a thirty-second run can miss it entirely.
And instrumentation is not free. Tools that capture frame times consume resources themselves, which is tolerable if the overhead is understood and misleading if it is not.
What transfers
The reason this is worth the attention of people who do not play games is that the discipline arrived at conclusions that generalise well.
Report distributions rather than point estimates. Instrument the whole path rather than the component you happen to control. Test under realistic load rather than convenient load. Treat variance as a first-class problem rather than noise around a mean.
None of that is novel to anyone doing serious performance work. What makes the gaming case instructive is the feedback loop: the user sees the tail latency directly, immediately, and complains about it in public. Few domains make the cost of a bad distribution quite so visible.