A bottleneck is not a defect. Every balanced system is limited by something, and the goal is to know which component sets your ceiling before you spend money.
- The fastest diagnostic is resolution scaling: if lowering resolution raises your frame rate, the GPU was the limit; if it does not move, the CPU is.
- CPU-limited systems show one or two cores pinned near 100% while the GPU sits well below full utilisation. GPU-limited systems show the reverse.
- Bottlenecks are per-workload, not per-machine: the same PC can be CPU-limited in a strategy game and GPU-limited in the same session at a higher resolution.
- SystemCheck measures CPU and GPU throughput separately across its stages, so a large imbalance between the two is visible without any additional tooling.
What a bottleneck actually means
In any pipeline, throughput is set by the slowest stage. In a PC rendering frames, the CPU prepares work (game logic, physics, draw call submission, asset streaming) and the GPU executes it. Whichever finishes its share last determines the frame rate. That component is the bottleneck.
The word carries a negative charge it does not deserve. Something is always the limit. A perfectly balanced system does not exist and would not be desirable if it did, because the balance point shifts with every change of resolution, settings preset, and application. What matters is whether the limiting component is the one you would expect, and whether the imbalance is large enough to be worth money.
The resolution test
This is the most reliable single diagnostic available and it needs no tools. Run your workload at its normal resolution and note the frame rate. Then drop it dramatically (4K to 1080p, or 1080p to 720p), keeping every other setting identical, and note it again.
Lowering resolution reduces the GPU's per-frame work almost linearly while leaving the CPU's work essentially unchanged: the same number of draw calls, the same physics, the same game logic. So the interpretation is clean. If the frame rate rises substantially, the GPU was the constraint and you have just relieved it. If the frame rate barely moves, the CPU was already the constraint and reducing GPU work changed nothing.
The same logic runs in reverse. Raise resolution or enable heavier GPU effects; if the frame rate falls sharply you were GPU-limited, and if it holds you had GPU headroom to spend.
Reading utilisation correctly
Utilisation figures are useful but routinely misread. GPU utilisation is a reasonably honest signal: a GPU sitting at 95-100% during a demanding scene is the limit; one hovering at 60% is waiting for work and something upstream is the constraint.
CPU utilisation is far more misleading, because most tools report an average across all logical processors. A game that fully saturates two cores on a sixteen-thread CPU shows roughly 12% total utilisation while being completely CPU-limited. The number you need is per-core, and the signature of a CPU bottleneck is one or two threads pinned near 100% while the aggregate looks idle.
This matters for how you interpret SystemCheck's results too. Stage 1 deliberately loads every logical processor because it is measuring the CPU's sustained capability, not simulating a game. A strong Stage 1 result tells you the CPU has multi-core throughput available; it does not promise that a lightly-threaded application can use it.
What SystemCheck can and cannot tell you here
SystemCheck measures CPU throughput and GPU throughput separately, under loads calibrated to saturate each in turn, and derives a bottleneck indication from the relationship between them. That is genuinely useful as a structural signal: it tells you whether the two halves of your system are broadly matched, and which one is comparatively weak.
What it cannot do is predict the bottleneck in a specific application, because that depends on the application's own mix of CPU and GPU work, your resolution, your settings, and your driver. A browser also cannot read GPU utilisation, VRAM capacity, or power draw. Those APIs do not exist on the web platform. SystemCheck's bottleneck indication is derived from measured throughput on both sides, not from utilisation counters it has no access to.
For per-application diagnosis, use the resolution test plus an in-game overlay: MSI Afterburner with RivaTuner, the built-in overlays in AMD Adrenalin and NVIDIA's app, or a game's own performance display. Those see the counters a browser cannot.
Frame-time shape as a diagnostic
Average frame rate hides the character of a bottleneck; frame-time graphs expose it. A GPU-limited system typically produces a smooth, consistent frame time. The GPU is saturated and delivering steadily, just not quickly. A CPU-limited system tends to produce a spikier trace, because CPU work per frame is uneven: an asset streams in, a physics step goes long, a shader compiles, and one frame takes three times as long as its neighbours.
So a smooth line at a disappointing frame rate points to GPU; an erratic line at a decent average points to CPU or to something outside both, such as storage or a background process. SystemCheck's Stage 2 stability figure captures this same property for its own GPU load, which is why a low stability score with reasonable throughput usually means contention rather than a weak GPU.
What to do once you know
If the GPU is the limit, you have the pleasant problem: lower settings or resolution, enable upscaling, or upgrade the GPU. GPU-limited systems also respond well to being left alone, because they are usually running smoothly, just at a lower frame rate than you want.
If the CPU is the limit, upgrading the GPU will do nothing and this is the expensive mistake worth avoiding. Look first for the free wins: background processes stealing cores, a power plan capping clocks, memory running below its rated speed profile, or thermal decay eating your sustained clocks. Only after those are ruled out is a CPU or platform upgrade the answer.
And if the imbalance is small, do nothing. A system where neither component is dramatically ahead of the other is a well-matched system, and chasing perfect balance is not a productive use of money.
Step by step
- 01
Run a baseline SystemCheck benchmark
Run all four stages on a quiet machine and record CPU sustained throughput, GPU frame time and stability, and path-tracing samples per second. This gives you both halves of the system measured under comparable conditions and a structural bottleneck indication.
- 02
Check for a large structural imbalance
Compare the CPU and GPU results against each other. If one side is dramatically stronger than the other, the weaker side sets your ceiling in any workload that leans on it. If they are broadly comparable, the bottleneck will shift with the workload rather than sitting in one place.
- 03
Run the resolution test in your actual workload
Open the application you care about, note the frame rate at your normal resolution, then drop the resolution sharply with all other settings unchanged. A large frame-rate gain means GPU-limited; little or no change means CPU-limited.
- 04
Confirm with per-core utilisation
Open an overlay or Task Manager set to show individual logical processors. One or two cores pinned near 100% while the GPU sits below 90% confirms a CPU bottleneck. GPU near 100% with all cores well below confirms a GPU bottleneck.
- 05
Inspect the frame-time trace, not just the average
Watch the frame-time graph rather than the frame-rate counter. Smooth pacing at a low rate points to the GPU. Irregular spikes at a decent average point to the CPU, to storage, or to a background process competing for cores.
- 06
Rule out the free causes before spending money
Check that the machine is on a high-performance power plan and mains power, that memory is running its rated XMP or EXPO profile, that background applications are closed, and that SystemCheck's decay figure is not showing the CPU losing sustained clocks to heat. Any of these can masquerade as a hardware bottleneck.
- 07
Re-measure after each change
Change one variable at a time and re-run both the SystemCheck benchmark and your real workload. A difference smaller than about 3% is measurement noise, not an improvement. Hold that standard even when it is disappointing.
Terms used here
Questions
- Is having a bottleneck bad?
- No. Every system is limited by something; a bottleneck simply names which component sets the ceiling. It only becomes a problem when the imbalance is large enough that one component is substantially idle while the other is saturated, or when the limiting component is not the one you paid to prioritise.
- Can a browser benchmark detect my GPU utilisation?
- No. There is no web API for GPU utilisation, VRAM capacity, or power draw. SystemCheck derives its bottleneck indication by measuring CPU and GPU throughput separately under calibrated loads and comparing them, not by reading utilisation counters. For real-time utilisation, use MSI Afterburner or your vendor's overlay.
- Why does my bottleneck change between games?
- Because it is a property of the workload, not of the machine. A strategy game simulating thousands of units is CPU-heavy; the same PC running a graphically dense shooter at 4K is GPU-heavy. Resolution alone shifts the balance point, which is why the resolution test works.