Frame time is the interval, measured in milliseconds (ms), between the completion of one rendered frame and the next. In gaming performance, it is the inverse of frame rate: a game running at 60 frames per second averages 16.7 ms per frame, while 144 fps corresponds to about 6.9 ms.
Frame rate summarizes performance as an average over a second, but frame time shows every individual frame. That makes it the more precise measure of smoothness, because a game can report a healthy average while occasional long frames cause visible hitches. Analyzing frame time is how reviewers and players identify stutter, poor frame pacing and their causes.
How frame time relates to frame rate
The conversion is simple: frame time in milliseconds equals 1,000 divided by frames per second. The relationship is not linear, which matters in practice. Raising frame rate from 30 to 60 fps saves 16.7 ms per frame, while raising it from 120 to 240 fps saves only 4.2 ms, so each further increase brings a smaller gain in responsiveness.
The table lists common targets and the frame time budget a game must meet to sustain them.
| Frame rate | Frame time budget | Typical use |
|---|---|---|
| 30 fps | 33.3 ms | Console quality modes, demanding games |
| 60 fps | 16.7 ms | Standard target for smooth play |
| 120 fps | 8.3 ms | High refresh rate displays, console performance modes |
| 144 fps | 6.9 ms | Common PC gaming monitors |
| 240 fps | 4.2 ms | Competitive shooters |
| 360 fps | 2.8 ms | Esports-oriented displays |
Because the budget shrinks as the target rises, a 2 ms hitch that is barely noticeable at 30 fps consumes a large share of the budget at 240 fps. High refresh rate gaming therefore demands tighter frame time consistency, not just more raw performance.
What determines the time needed for one frame
Each frame passes through a pipeline of CPU and GPU work, and frame time is set by the slowest stage. The CPU runs game logic, physics, animation and draw call submission; the GPU then renders geometry, lighting and post-processing. When one side takes longer, the other waits, which is what the terms CPU bottleneck and GPU bottleneck describe.
| Cause | Stage affected | Typical symptom |
|---|---|---|
| Shader compilation | CPU and driver | Single spikes of 50 ms or more when new effects appear |
| Asset streaming | Storage, CPU, memory | Hitches when entering new areas |
| CPU-heavy simulation | CPU main thread | Consistently high frame time in crowded scenes |
| GPU overload | GPU | Steadily long frames at high resolution or settings |
| Video memory overflow | GPU and memory bus | Irregular spikes and texture pop-in |
| Background tasks | CPU | Random isolated spikes |
Some causes produce consistently long frames, which simply lower the frame rate, while others produce isolated spikes, which are perceived as stutter even when the average looks fine. Distinguishing the two patterns is the main purpose of frame time analysis.
Frame time metrics used in benchmarks
Game benchmarks record frame time for every frame and then summarize the distribution. The frame time graph is the most direct view: a flat line indicates smooth delivery, while sharp upward spikes reveal hitches. Statistical summaries such as 1% lows translate the slowest frames back into frame rate terms.
| Metric | How it is calculated | What it reveals |
|---|---|---|
| Average fps | Total frames divided by total time | General performance level |
| 1% low fps | Based on the slowest 1 percent of frames | Severity of regular slowdowns |
| 0.1% low fps | Based on the slowest 0.1 percent of frames | Rare but severe hitches |
| 99th percentile frame time | Frame time exceeded by only 1 percent of frames | Worst typical frame in milliseconds |
| Frame time variance | Spread of consecutive frame times | Consistency of frame pacing |
Tools differ in how they calculate lows, so figures from different tools are not always comparable. The most reliable comparison uses the same tool, the same scene and repeated runs.
Frame time consistency, frame pacing and input lag
Smoothness depends less on the average frame time than on how evenly frames are delivered. A game alternating between 10 ms and 23 ms frames averages about 60 fps yet looks worse than a steady 16.7 ms cadence. This even delivery is called frame pacing, and poor pacing is often more noticeable than a lower frame rate.
Frame time also contributes directly to input lag, because an action cannot appear on screen until the frame containing it is finished. Shorter frame times reduce latency, while queued frames increase it. Technologies such as NVIDIA Reflex shorten the render queue, and variable refresh rate (VRR) displays such as G-SYNC and FreeSync adapt the refresh interval to each frame time, hiding moderate variation.
How to improve frame time stability
Improving frame time starts with identifying whether the problem is long frames or uneven frames. The decision table pairs common observations with effective measures.
| Observation | Recommended measure | Why it helps |
|---|---|---|
| Fluctuating frame rate | Set a frame rate cap below the typical minimum | Keeps frame time steady |
| Spikes on first play | Let the shader cache build or precompile shaders | Removes compilation stalls |
| GPU at full load | Lower resolution, enable upscaling | Shortens GPU render time |
| CPU at limit, GPU idle | Reduce crowd density and simulation settings | Shortens CPU frame time |
| Tearing or judder | Use VRR with a cap a few fps below refresh | Matches display timing to frames |
In plain words
Frame time is how long each picture takes to appear on the screen. A game shows many pictures every second. If each one takes the same amount of time, motion looks smooth. If some take much longer than others, the game seems to jump or hiccup.
Think of a drummer keeping a beat. A steady rhythm feels right even at a slow tempo. A fast drummer who sometimes pauses sounds wrong. Games work the same way: an even rhythm matters more than the highest possible speed.
A real-world example
A player with a 144 Hz monitor reports that an open-world game averages about 110 fps, yet camera turns feel rough. The frame time graph from a benchmark run shows a baseline near 9 ms, interrupted every few seconds by spikes of 35 to 40 ms. The 1% lows sit near 30 fps, far below the average.
Monitoring shows the GPU only partly loaded while one CPU thread is at its limit during spikes, which points to asset streaming on the CPU. The player lowers crowd density, moves the game to a faster SSD and sets a frame rate cap of 90 fps with VRR enabled. The average drops slightly, but the spikes shrink to about 14 ms and the 1% lows rise above 70 fps. The result is noticeably smoother gameplay despite the lower headline number.