Frame Time and 1% Lows: The Smoothness Metrics
Learn how frame time and 1% lows reveal stutter that average FPS hides, then use repeatable captures to separate limits from one-off spikes.
Read Frame Time and 1% Lows: The Smoothness Metrics → Symptom-led playbook
A Repeatable Way to Find What Is Causing PC Stutter
Short answer: Stutter is a delivery-time problem, not a component name. Its timing matters. A first-visit hitch, a repeating spike and a gradual loss of smoothness can share a poor 1% low. They can still come from completely different stages of the PC.
Classify the stutter by timing before changing settings
Record a frame-time graph during the exact scene where the interruption occurs. Note whether the spike happens once or repeats. Mark whether it appears during rapid traversal or grows as the system warms. That pattern narrows the investigation more effectively than an average FPS counter.
Separate expected transitions from faults. A loading screen or save can create an isolated slow frame. A first encounter with a new shader can do the same. Continuous uneven delivery during ordinary play deserves a different test.
- One-time first-use hitches point toward compilation, cache creation or asset loading.
- Traversal spikes raise questions about storage, decompression, RAM and VRAM residency.
- Regular periodic spikes suggest polling, overlays, background services or scheduled work.
- A worsening warm trace calls for clock, power and temperature logging.
Correlate the slow frame with the resource event
Capture frame time beside per-core CPU activity, GPU clock and utilization, dedicated VRAM, committed system memory, disk active time and temperatures. The 20-minute bottleneck test provides a controlled baseline. A graph matters because a utilization average can conceal the short event that caused the visible hitch.
Do not assume a disk spike proves a slow drive. The game may be reading because memory is full, compiling because a cache was invalidated, or requesting an asset for the first time. Compare a cold pass with a warm repeat, then use the PC performance baseline playbook to keep the route, warm-up and software state consistent.
- Mark the timestamp of every visible hitch instead of watching gauges live.
- Compare allocation with capacity for both RAM and VRAM.
- Record effective clock and limit flags, not temperature alone.
- Repeat the same route enough times to distinguish first-pass work from persistent work.
Apply one cause-specific change and demand a repeatable response
Change the variable most directly connected to the evidence. Lower textures for VRAM pressure, reduce a CPU-heavy simulation setting for a critical-thread spike, close one overlay for a periodic interruption, or compare a warm route when shader creation is suspected. Restore the baseline before testing the next theory.
A hardware purchase is justified only when the remaining stutter is repeatable, the relevant resource is operating normally and the proposed part changes that path. Use the CPU-or-GPU upgrade decision only after memory pressure, storage events, caps, software hooks and thermal decline have been ruled in or out.
- Keep image quality unchanged when testing a background-process theory.
- Keep the route unchanged when testing storage or shader-cache behavior.
- Judge the frequency and magnitude of spikes, not only the average FPS.
- Save the fixed trace as a reference for future driver and game updates.
Choose the next test from the evidence
| Scenario | Signal or scale | Best next check |
|---|---|---|
| Only on the first pass | Compilation, cache or first asset request | Repeat the identical warm route |
| During rapid traversal | Asset delivery, memory residency or decompression | Correlate RAM, VRAM and disk activity |
| At a regular interval | Overlay, polling or background service | Use a clean-start comparison |
| Worse after warm-up | Thermal, power or memory leak | Log clocks, limits and allocation over time |
| Only when frame rate is uncapped | CPU/GPU saturation or queue pressure | Test a sustainable cap |
Use tools to test a question, not manufacture certainty.
Start with the CPU and GPU bottleneck calculator, convert refresh targets with the FPS to frame-time calculator, or work through the diagnostic checklist.
Focused evidence
View the complete PC bottleneck guide →Continue with a specific guide
How to Check a PC Bottleneck in 20 Minutes
Use a repeatable 20-minute test with utilization, frame time, temperatures and controlled setting changes to identify the part limiting your PC.
Read How to Check a PC Bottleneck in 20 Minutes →RAM Bottlenecks: Capacity, Channels and Latency
Diagnose RAM bottlenecks by checking capacity, paging, channel layout, data rate and latency when CPU and GPU measurements do not explain poor 1% lows.
Read RAM Bottlenecks: Capacity, Channels and Latency →Can an SSD Be a Gaming Bottleneck?
Learn when storage can cause gaming stutter, how to separate loading and asset-streaming delays from FPS limits, and when an SSD upgrade helps.
Read Can an SSD Be a Gaming Bottleneck? →Thermal Throttling vs. a Hardware Bottleneck
Two problems can look identical in an FPS graph. Here is how to tell falling clocks from an underpowered component.
Read Thermal Throttling vs. a Hardware Bottleneck →