Why a Bottleneck Percentage Is Not a Real Number

Data reviewed September 12, 2026 · Methodology

What those calculators compute, the weights ours uses, and how to measure the real answer in five minutes.

Type any two parts into most bottleneck sites and you get something like “17.4% CPU bottleneck”. The precision is the tell. A percentage to one decimal place implies a measurement, and no measurement took place: the tool looked up two numbers in a table and divided them.

What the number actually is

Underneath, almost every such tool does the same three things. It assigns each CPU and each GPU a single score, divides one by the other, and maps the result onto a sentence. That is a reasonable way to compare tiers. It stops being reasonable the moment the output is dressed up as a measured percentage, because the divide loses everything that decides the real answer: which game, which scene, which settings, whether upscaling is on, and what frame rate you are aiming at.

An example. A Ryzen 5 5600 with an RTX 5070 is CPU-limited in a heavily simulated strategy game at 1080p and GPU-limited in the same build running a path-traced scene at 4K. One percentage cannot describe both, so a tool that prints one is describing neither.

The weights our estimator uses

We publish these so the output can be argued with. The bottleneck estimator computes a single ratio:

ratio = (CPU index × resolution weight) ÷ (GPU index × resolution weight × game-type weight × target weight)

A higher ratio means the GPU runs out first. The multipliers are fixed constants, not per-card data:

Target frame rate applies one more multiplier on the GPU side: 0.78 at 60 FPS, 1.00 at 120, 1.12 at 144 and 1.42 at 240. Aiming higher makes a CPU limit more likely, which is why a 240Hz esports player and a 60Hz single-player fan can own the same two parts and need different advice.

The ratio is then mapped to five bands: below 0.70 strong CPU-limit risk, below 0.90 possible CPU limit, up to 1.25 balanced, up to 1.55 GPU-limited (healthy), above that GPU-limited (expected). Those thresholds are judgement calls. They are not derived from benchmark data, and we would rather say so than hide them behind a decimal point.

The five-minute test that gives a real answer

If you already own the parts, stop reading calculators. This produces an actual answer for your actual game.

1. Turn on an overlay that shows GPU utilisation, per-core CPU utilisation and frame time. Any of the common vendor or third-party overlays will do.
2. Load the game and scene you actually care about — the busy town, the late-game base, the 64-player map. A menu or a benchmark run will mislead you.
3. Play for two minutes at your normal settings and watch GPU utilisation. Sitting at 95–99% means the GPU is the limit, and that is the healthy case.
4. If GPU utilisation sags to 70–85% while one CPU core is pinned near 100%, you have found a CPU limit in that scene.
5. Confirm it: drop the resolution one step. If the frame rate barely moves, the CPU is setting the ceiling. If it jumps, the GPU was.

What we will not tell you

We will not print a percentage, a predicted FPS figure or a “you are losing 23% performance” line, because we cannot compute any of them honestly from tier indices. What the pair pages give you instead is a band, the two indices behind it, and how the band moves across resolutions. That is less satisfying and considerably more useful.