Stutter and a low average FPS are different faults with different cures, and the fastest way to tell them apart is to stop reading the FPS counter and start recording frame times. Three causes produce three recognisable shapes: overheating drops performance gradually after a few minutes and holds it down, memory pressure gives long freezes with disk activity behind them, and a background process throws single spikes at intervals. Intel's PresentMon records the per-frame data for free; the rest of this guide is how to read it.
Short answer
- Record frame times, not average FPS. One 50 ms frame per second is invisible in an average and very visible to you.
- Heat looks like a slow decline that never recovers until you stop playing; clocks fall while temperature sits at a ceiling.
- Memory pressure looks like long freezes with disk activity, not like a lower average.
- A background process looks like isolated spikes at intervals — a scan, a sync, an update check.
- Change one thing at a time and re-measure. Two changes at once means you learn nothing from either.
Measure frame time, not average FPS
An average is a summary of a second. The frame that ruined the fight lasted 50 ms, and thirty smooth frames around it hide it completely. So capture the frames themselves.
Intel PresentMon is the reference tool here, and it is open source. It traces CPU, GPU and display frame durations and latencies, works across DirectX, OpenGL and Vulkan, and writes per-frame CSV.
The service version adds hardware telemetry — GPU power, temperature and utilisation pulled from vendor APIs such as NVAPI — so temperature and frame time land on the same timeline. NVIDIA FrameView, AMD OCAT, CapFrameX and RivaTuner Statistics Server are all built on that same collection library.
Two practical notes from the project's own documentation, both of which cost people an evening:
- You need to be in the "Performance Log Users" group. Otherwise the capture fails with "failed to start trace session (access denied)".
- OpenGL and Vulkan titles report less. They show a runtime of "Other", their CPU frame-pacing stall is always reported as 0, and CPU frame time is slightly less accurate.
Also worth knowing before you trust a number: with Hardware-Accelerated GPU Scheduling enabled, the project states GPU execution metrics are less accurate and can be reported larger than they should be.
Is the drop thermal?
Usually you can answer this in one session, without touching a screwdriver. Thermal throttling has a shape that nothing else copies: the first minutes are fine, temperature climbs and then flattens at a ceiling, and from that moment the clock falls while the workload has not changed.
That last part is the actual test. Temperature alone proves nothing — a chip sitting at its limit while holding full clocks is doing its job. What matters is whether the clock drops when the temperature stops rising.
Two physical causes sit behind most of it, and both are named in the PC Optimization Hub: clogged heat sinks and dust filters reduce airflow and therefore heat dissipation, and ambient temperature moves component temperatures enough to matter — the same machine behaves differently in July and January.
If your throttling is on a laptop, the cheap wins are on the outside of the case: raise the back, clear the intakes, and re-test at the same time of day. Games that were already at the edge of a weak machine deserve the settings pass in the Minecraft on a low-end PC guide — the principles carry over to any engine.
Is it memory, or the page file?
Memory pressure does not look like a lower average. It looks like the game freezing for a second or more, with the disk busy underneath, and then continuing as if nothing happened.
Microsoft's description of the page file explains why: it is an optional hidden system file that lets Windows remove infrequently accessed modified pages from physical memory so that RAM serves the pages being used more often. When a game asks for more than is comfortably available, that removal happens while you are playing, and it goes at the speed of your storage.
So the test is not "how much RAM do I have" but "is the system paging during the session". Watch committed memory over a whole play session rather than at the menu, and watch disk activity at the moment of the freeze. If both spike together at the freeze, it is memory. If neither moves, stop buying RAM.
Microsoft also publishes guidance on sizing the page file, and their framing is worth keeping: the page file backs system crash dumps and extends how much system-committed memory the machine supports. It is not a performance feature you tune for FPS.
The background process problem
The signature here is periodicity. Not a decline, not a freeze under load — a spike that arrives on a schedule, often when you are doing nothing unusual.
Valve's list of programs that may interfere with games names the categories directly: antivirus that hooks deep into disk operations, recording software, download managers and accelerators, P2P clients, system cleaners, IP filtering tools. Their advice is to disable them for testing, which is exactly the right verb — you are proving a cause, not permanently crippling your security.
Two specific ones deserve a mention because they are self-inflicted:
- A store download running while you play. It competes for the same disk and the same network. If yours is permanently slow anyway, the Steam download guide covers the settings that change it.
- A monitoring overlay. The PC Optimization Hub notes that monitoring programs themselves have a large performance impact and advises against running them while stress testing. Measuring with a heavy tool changes the thing you are measuring.
For the load picture, Task Manager is a starting point rather than evidence: the same source points out it shows core usage superficially and does not account for context switching, and recommends Sysinternals Process Explorer for a real view and Autoruns for what actually starts with Windows.
Settings that change frame time, and settings that only change the average
Not every graphics option affects stutter. Resolution and texture quality mostly move the average; the ones that produce spikes are the ones that make the engine do work in the middle of a scene — streaming distance, shadow and reflection resolution, and anything that loads new assets as you move.
The honest method is boring and it works: change one setting, replay the same route, compare frame time graphs. A route matters more than a benchmark scene here, because stutter lives in transitions — entering a new area, first sighting of a new effect, a fight after a quiet corridor.
Our per-game settings guides are built the same way, with the reasoning attached rather than a copied preset: Apex Legends, Fortnite and Roblox FPS. Launch flags are a separate lever with a lot of dead advice around it — the CS2 launch options guide marks which ones the engine still reads.
When the stutter is not in the frames at all
This one surprises people. If the picture is smooth on a frame time graph but aiming feels like it is skipping, the problem is on the input side, and no graphics setting will touch it.
Two checks separate the cases in under a minute. The polling rate test shows how often your mouse actually reports, so a device silently dropping from its advertised rate stops being a theory. The mouse test shows cursor tracking and the event rate on a pad, and catches freezes and jumps that come from the sensor, the cable or USB power saving rather than from the GPU.
If everything feels slow rather than one game, the reaction time test gives you a baseline that is not coloured by that evening's match.
A full input-side walkthrough lives in mouse lag and stutter; if keys are dropping instead, go to keyboard not working in game.
What usually goes wrong
- Chasing the average. Symptom: the counter reads 140 and the game feels awful. Why: averages hide spikes. Fix: capture frame times and look at the worst frames of the session.
- Judging heat by one glance at a number. Symptom: "it's 80 degrees, that's the problem". Why: a chip at its limit holding full clocks is fine; throttling is a clock drop. Fix: log clocks and temperature together and look for the moment they diverge.
- Testing with a monitoring overlay running. Symptom: results change when you enable logging. Why: monitoring tools have a measurable performance cost. Fix: log to CSV instead of watching an overlay, and compare like with like.
- Changing five settings at once. Symptom: it got better, and nobody knows why. Why: no isolation. Fix: one change, one re-measure, written down — the methodology the PC Optimization Hub opens with.
- Blaming the GPU for a stutter that arrives every three minutes. Symptom: regular spikes, low GPU load. Why: a scheduled scan, sync or update check. Fix: disable the suspects for one test session, then re-enable them one at a time.
The useful outcome of an evening like this is not a settings preset, it is a sentence: "my stutter is heat", or "my stutter is a background scan". Once you have that sentence, the fix is usually cheap and specific. And if the game does not merely stutter but closes on you, the diagnosis is different again — that path starts at game crashes on startup.
FAQ
Why does my FPS counter look fine while the game stutters?
Because an average hides the frames that hurt. A single 50 ms frame inside a second of 8 ms frames barely moves the average, and it is exactly the one you feel. Capture frame times instead: Intel's PresentMon records CPU, GPU and display frame durations per frame, and NVIDIA FrameView and AMD OCAT are built on the same data. Look at the spikes, not the mean.
How do I tell thermal throttling from anything else?
By watching clocks and temperature together over several minutes rather than glancing at one number. Throttling has a signature: performance is normal at first, temperature climbs to a ceiling and stops there, and the clock drops while the load stays the same. The PresentMon service reads GPU power, temperature and utilisation from the vendor APIs, so you can log all of it alongside frame times.
Does adding RAM fix stutters?
Only if memory is actually the constraint, and that is testable before you buy anything. Watch committed memory over a session: if the game is repeatedly pushing the system to page out, that is memory pressure. Microsoft describes the page file as an extension that lets Windows remove infrequently accessed modified pages from physical memory, so the disk activity that accompanies it is the tell.
Should I close background programs before playing?
Test with them closed, then decide. Valve's own list of programs that may interfere names antivirus, recording software, download managers, P2P clients and system cleaners, and asks you to disable them for testing. Anything scanning the disk or saturating the network while you play competes with the game for the same resources.
Is Task Manager good enough for diagnosing stutters?
For a first look, yes; for a verdict, no. It shows CPU load at a very superficial level and does not account for costs such as context switching, which is why the PC Optimization Hub recommends Sysinternals Process Explorer and Autoruns instead. Frame times still have to come from a frame capture tool, not from a load percentage.
Sources
- Intel PresentMon: what it captures, service telemetry and known limitations
- NVIDIA FrameView: frame time and power capture tool
- Microsoft Learn: introduction to page files
- Microsoft Learn: how to determine the appropriate page file size
- Steam Support: Programs Which May Interfere with Steam
- Steam Support: Update & Installation Issues (overclocking and driver advice)
- PC Optimization Hub: measurement methodology, peripherals, cooling notes
- Microsoft Sysinternals: Process Explorer