Frame time graphs are the single most honest piece of feedback your PC can give you about how a game is actually running. When I first started chasing stutter in competitive shooters, I wasted weeks blaming hardware that was never the problem, because I was reading the wrong number. Learning how to read a frame time graph changed the way I diagnose performance issues forever, and it will do the same for you.
An FPS counter is a summary, and summaries lie. A frame time graph shows the truth, frame by frame, in milliseconds. This guide walks through exactly how to read one, what each pattern means, and how to connect a specific spike shape to the hardware, driver, or engine issue that is actually causing your stutter.
By the end you will be able to look at a graph for ten seconds and know whether you are dealing with shader compilation, traversal stutter, thermal throttling, a background process, or a VRAM overflow. That is the level of diagnosis this article is built to deliver, and it works for everything from a 60 Hz single-player playthrough to a 240 Hz ranked match.
Table of Contents
Why FPS Alone Lies to You
FPS is an average, and averages are designed to hide outliers. If nine frames take 8 ms each and the tenth takes 80 ms, your counter still happily reports “120 FPS” because the math averages out. Your eyes, however, see that single 80 ms frame as a full stutter, and the FPS number never warned you it was coming.
This is the gap frame time fills. Instead of telling you how many frames arrived in a second, it tells you how long each individual frame took. The difference sounds small, but it is the entire reason a game can average 144 FPS and still feel worse than a locked 60 FPS experience. I have personally tested builds where the FPS counter looked flawless and the frame time graph looked like a seismograph during an earthquake.
Once you accept that FPS is a marketing number and frame time is a diagnostic number, every stutter investigation gets faster. You stop guessing, you start reading, and the graph tells you what to fix.
What Is a Frame Time Graph?
A frame time graph displays how long each individual frame takes to render in milliseconds, with time on the horizontal axis and frame time on the vertical axis. Lower is better, and a flat line is the holy grail. Every upward spike is a frame that took longer than expected, and every spike is a frame your eyes will register as a hitch, stutter, or freeze.
Frame time is measured in milliseconds per frame, and the relationship to FPS is a simple inversion: 1000 divided by FPS equals frame time in ms. This is why 60 FPS equals 16.7 ms per frame, 120 FPS equals 8.3 ms, and so on. The math is fixed, which makes target values easy to remember.
Target Frame Times at Common Refresh Rates
Here is the quick reference I keep taped to my monitor. Match your graph’s baseline to your monitor’s refresh rate:
- 60 Hz target: 16.7 ms per frame
- 75 Hz target: 13.3 ms per frame
- 120 Hz target: 8.3 ms per frame
- 144 Hz target: 6.9 ms per frame
- 165 Hz target: 6.1 ms per frame
- 240 Hz target: 4.2 ms per frame
- 360 Hz target: 2.8 ms per frame
If your graph hovers flat near your target value, your system is delivering frames consistently. If the baseline sits well above target, you are GPU- or CPU-bound and need to lower settings or upgrade. If the baseline is on target but spikes shoot upward periodically, you have a stutter problem, and the rest of this article is about identifying which kind.
Tools to Capture a Frame Time Graph
You cannot read a graph you do not have, so the first step is choosing a capture tool. The right tool depends on how deep you want to go, but for most users the combination below covers 95 percent of stutter investigations.
MSI Afterburner with RivaTuner Statistics Server (RTSS)
This is the free, industry-standard pairing that most enthusiasts, including me, use daily. MSI Afterburner handles GPU monitoring and the on-screen overlay, while RTSS provides the frame time graph, the framerate limiter, and the data logging. The on-screen frame time graph is small, always visible, and updated in real time, which makes it perfect for catching stutter the moment it happens.
RTSS also includes the best frame rate limiter available on Windows, and a hard cap is one of the easiest stutter fixes you will ever apply. Set the cap a few FPS below your monitor’s refresh rate when using G-Sync or FreeSync to keep the frame time graph pinned to a single value.
CapFrameX
CapFrameX is a free analysis tool built on top of PresentMon that records a session and then gives you a clean frame time graph plus the 1% low, 0.1% low, and averages in a single view. I reach for CapFrameX when I want to compare two settings side by side, because it overlays the runs and makes the difference obvious.
NVIDIA Frame View and AMD OCAT
These are vendor-provided capture tools that log the same underlying data as PresentMon but with vendor-specific tagging. They are most useful if you want to measure latency alongside frame time, which matters for competitive shooters. For pure stutter diagnosis, RTSS or CapFrameX is simpler.
PresentMon Alone
PresentMon is the open-source tracer that most of these tools run underneath. If you are comfortable with command-line tools and CSV files, running PresentMon directly gives you the rawest data possible. This is overkill for most users, but it is the most accurate option when you need to defend a benchmark result online.
How to Read a Frame Time Graph
This is the core skill. Once you know how to read a frame time graph, every other section in this article becomes a reference rather than a tutorial. The process below is the exact workflow I use whenever a new stutter shows up in any game.
Step 1: Identify the Baseline
Read the flat portion of the graph first. That baseline is your average frame time, and it tells you whether your system is hitting your target refresh rate. If the baseline sits at 7 ms on a 144 Hz monitor, you are GPU-bound or CPU-bound and the fix is settings or hardware. If the baseline sits at the target value, your average performance is fine and any problem is in the spikes, not the average.
Step 2: Look at the Spikes
Spike shape is the single most diagnostic feature on the graph. A single sharp vertical line is a different problem than a cluster of medium spikes, which is again different than a slow upward drift. The pattern library later in this article maps each shape to a cause, and after a few weeks of practice you will recognize them on sight.
Step 3: Check the Periodicity
If spikes repeat at a steady interval, you are almost certainly looking at a background process. Spikes every second point to antivirus scans, Windows telemetry, or scheduled tasks. Spikes tied to camera movement point to engine streaming or traversal stutter. Random spikes with no rhythm point to thermal throttling, VRAM overflow, or driver issues. The rhythm is the clue.
Step 4: Read the 1% Low and 0.1% Low
The 1% low is the average frame time of your worst 1% of frames, converted back to FPS. The 0.1% low is the same calculation for the worst 0.1%. These two numbers tell you how the worst moments feel, and they are the metric I trust more than any average.
A clean experience needs your 1% low within about 70% of your average FPS, and your 0.1% low within about 50%. If you average 120 FPS and your 1% low sits at 40 FPS, the average is hiding a stutter problem that the graph will show clearly. CapFrameX and RTSS both report these numbers automatically, and they are the single best single-number summary of perceived smoothness.
Step 5: Compare With and Without the Suspected Cause
The final step is the controlled test. Disable the suspected cause, replay the same scene, and compare the two graphs. If the spikes vanish, you have your answer. If they persist, you have eliminated one possibility and can move on. This sounds obvious, but it is the step most people skip, and it is the reason most stutter investigations drag on for weeks.
Common Frame Time Patterns and What Causes Them
This is the pattern library. Each entry describes the visual signature on the frame time graph, the most likely cause, and how to confirm it. Bookmark this section, because you will reference it every time a new stutter appears.
Pattern 1: Periodic Spikes at a Steady Interval
The signature is a sharp vertical spike repeating every 1 to 5 seconds with the rest of the graph dead flat. This is the most common pattern on a frame time graph, and in my experience it almost always traces back to a background process rather than the game itself.
The usual culprits are antivirus real-time scanning, Windows Defender scheduled scans, telemetry uploads, cloud sync clients, and RGB or peripheral software polling hardware on a timer. Open Task Manager, sort by CPU, and watch what spikes in sync with the graph. Disabling or excluding the game folder from your antivirus typically removes the pattern entirely.
Pattern 2: Camera-Movement-Linked Spikes
The spikes appear only when you rotate the camera or move quickly through the world, and the graph is otherwise flat. This is classic traversal stutter, and it is increasingly common in modern open-world games built on Unreal Engine 5.
The cause is the engine streaming in assets faster than the storage subsystem or the shader cache can deliver them. On older SATA SSDs and spinning hard drives this pattern is brutal. On a fast NVMe drive with DirectStorage enabled, it shrinks dramatically. If you see this pattern and you are still on a SATA SSD, the storage upgrade is the single highest-impact fix you can make.
Pattern 3: Clustered Spikes Early in a Session
The first few minutes of play show clusters of large spikes, then the graph flattens out and stays clean for the rest of the session. This is shader compilation stutter, and enthusiasts describe it as a design choice rather than a bug because of how modern DirectX 12 and Vulkan compile shaders on demand.
The cause is the engine compiling shaders the first time it encounters a new effect or geometry. The fix is to play through the affected area once and let the shader cache fill, then the spikes do not return for that scene in future sessions. Pre-compiling shaders, if the game offers it, eliminates the problem before you ever see it. A larger driver shader cache also helps, and both NVIDIA and AMD expose this option in their control panels.
Pattern 4: Spikes That Worsen Over Time
The graph starts flat and gradually grows noisier the longer you play, with spikes that get larger and more frequent in the last hour of a session. This pattern points at a leak or accumulation problem rather than a constant cause.
The two most common causes are VRAM overflow and memory leaks. VRAM overflow happens when texture and asset budgets exceed your GPU’s video memory, forcing the driver to spill into system RAM and tank frame times. A memory leak, whether in the game engine or a driver, slowly consumes RAM until the system starts paging. Closing and reopening the game confirms the diagnosis if the graph resets to clean, and lowering texture quality confirms VRAM overflow if the pattern weakens.
Pattern 5: Spikes Correlated With Fan Noise or Heat
The spikes appear after the system has been under load for a while, and they line up with rising temperatures or ramping fans. This is thermal throttling, and the frame time graph will show periodic spikes as the CPU or GPU clocks down to shed heat.
Confirm by logging clocks alongside frame time in MSI Afterburner or HWiNFO. If the core clock drops in sync with the frame time spike, heat is your cause. The fixes are physical rather than software: clean the cooler, repaste the CPU or GPU, improve case airflow, or cap the frame rate to reduce sustained heat load.
Pattern 6: Constant Noise Across the Entire Graph
The graph never flattens, even when standing still in a menu. There is no clean baseline at all, just a noisy band of values clustered around the target. This pattern is the hardest to diagnose because it has no single cause.
The usual suspects are DPC latency issues, HPET configuration, an unstable RAM or GPU overclock, an outdated chipset driver, or a system that needs its BIOS updated. Tools like LatencyMon isolate DPC latency, and reverting overclocks to stock confirms whether stability is the issue. This is the pattern where I would tell you to start with the basics: chipset drivers, BIOS, XMP or EXPO stability, and remove every overclock before chasing anything more exotic.
Quick-Reference: Pattern to Cause to Fix
- Steady periodic spikes -> background process -> exclude game from antivirus, disable RGB software
- Camera-linked spikes -> traversal stutter -> faster NVMe, enable DirectStorage, lower texture streaming pool
- Early-session clustered spikes -> shader compilation -> pre-compile shaders, enlarge driver shader cache
- Worsening spikes over time -> VRAM overflow or memory leak -> lower texture quality, restart session, check for game patch
- Heat-correlated spikes -> thermal throttling -> repaste, clean cooler, cap frame rate
- Constant noise -> DPC latency or unstable overclock -> run LatencyMon, revert to stock clocks, update BIOS
How to Fix the Stutter You Identified
Diagnosis only matters if you can act on it. The fixes below are organized by what the frame time graph told you, not by hardware component, because that is the order you will actually work in.
Cap Your Frame Rate
If your graph shows constant small variance around the target, the fastest fix is a hard frame rate cap in RTSS. A cap pins every frame to the same delivery time and removes the variance that your eyes perceive as micro-stutter. Set the cap three to four FPS below your refresh rate when using G-Sync or FreeSync, and the frame time graph will flatten into a single horizontal line.
Tighten Up Background Processes
For periodic spikes, the fix is software hygiene. Add your game folder to your antivirus exclusion list, pause cloud sync clients while playing, disable RGB and peripheral software that polls hardware, and run the game in fullscreen exclusive rather than borderless. These five changes clear the majority of one-second-interval spikes I have ever seen.
Upgrade Storage for Traversal Stutter
If camera-linked spikes dominate your graph, a fast PCIe 4.0 or 5.0 NVMe drive is the single most impactful upgrade you can make. DirectStorage-aware games pull assets in parallel rather than serially, which flattens traversal spikes dramatically. If your game supports DirectStorage and you are still on a SATA SSD, the upgrade is mandatory, not optional.
Pre-Compile and Cache Shaders
For shader compilation stutter, the fixes are preventive. Use the game’s pre-compile option if it has one, enlarge the driver shader cache in NVIDIA or AMD control panels, and accept that the first session in any new area will be noisy. The shader cache fills, the spikes disappear, and subsequent sessions stay clean.
Manage VRAM and Memory
For worsening-over-time spikes, the fix is reducing the asset budget. Drop texture quality one tier, disable ray tracing if VRAM is tight, and close background applications that reserve VRAM. If the graph still degrades, restart the game between sessions to confirm a leak and check for a patch, because leaks are usually fixed quickly by the developer.
Address Thermals and Stability
For heat-linked and noisy-graph patterns, the fixes are physical and electrical. Repaste the CPU and GPU, improve airflow, and revert any overclocks to stock to confirm stability. Update your chipset drivers and BIOS, enable XMP or EXPO for full RAM speed, and verify with MemTest86 if the noise persists. Resizable BAR is also worth enabling on supported systems, because it improves frame delivery in CPU-bound titles at no cost.
When Software Fixes Are Not Enough
If you have worked through every pattern and the graph still spikes, the frame time data is telling you that a component is genuinely the bottleneck. A CPU-bound graph with no other pattern is the clearest signal that a CPU upgrade is warranted. A GPU-bound graph that no settings reduction can fix is the signal that a GPU upgrade is next. The graph tells you which one, and that decision is exactly why this skill is worth learning.
FAQs
What causes stuttering in FPS?
Stutter in games is caused by frames that take longer to render than the target time, which the frame time graph shows as upward spikes. The most common causes are background processes creating periodic spikes, traversal stutter from asset streaming in open-world games, shader compilation in DirectX 12 and Vulkan titles, VRAM overflow, and thermal throttling.
How to fix choppy frame rate?
Start by reading the frame time graph to identify the pattern. Cap your frame rate in RTSS to flatten micro-stutter, exclude the game folder from your antivirus to kill periodic spikes, upgrade to a fast NVMe drive for traversal stutter, pre-compile shaders for early-session spikes, lower texture quality for VRAM-related stutter, and address thermals for heat-linked spikes.
How to read a frame time graph?
Read the baseline first to confirm you are hitting your target frame time, then examine spike shape, periodicity, and the 1% and 0.1% lows. A flat line near your target value indicates smooth performance, regular spikes point to background processes, camera-linked spikes indicate traversal stutter, and worsening spikes over time suggest VRAM overflow or a memory leak.
What does frame stuttering look like?
On a frame time graph, stutter appears as upward spikes breaking an otherwise flat baseline. Visually in-game, stutter looks like a momentary freeze, hitch, or judder that breaks the smooth flow of motion, often despite the FPS counter reporting a high average. A frame that takes 50 ms when the rest take 7 ms will look like a single frozen frame to your eyes.
Conclusion
Learning how to read a frame time graph is the skill that separates guessing from diagnosing. The graph tells you whether your problem is a background process, engine streaming, shader compilation, thermal throttling, VRAM overflow, or a genuine hardware bottleneck, and it tells you in seconds instead of weeks.
Start with MSI Afterburner and RTSS, capture a session in CapFrameX, match the pattern to one of the six signatures above, and apply the matching fix. Do this on every stutter you encounter and the FPS counter will become a marketing number to you, just as it has for every enthusiast who ever chased smoothness. That is the entire process, and it works in 2026 the same way it has always worked: read the graph, name the pattern, fix the cause.