Package & Share · Easy · 14 min
Performance Basics: Stat Commands and Scalability
Open the console, read your real frame rate with the stat commands, find out whether the CPU or GPU is the bottleneck, and use Engine Scalability and draw-call awareness to make your game run smoother — without guessing.
Before this: Press Play and Test Your Level for the First Time, Package Your Game for Windows: Make a Real .exe, Step by Step
- Open the Unreal console with the backtick key and run a command
- Read your real frame rate and timings with stat fps and stat unit
- Tell whether the CPU (Game) or the GPU is your bottleneck
- Use Engine Scalability and basic draw-call awareness as your first optimisation moves
Why "it feels slow" isn't enough
At some point every project starts to stutter — the camera judders, the editor feels heavy, or a packaged build runs worse than you hoped. The instinct is to start changing things at random and hope it helps. That almost never works, because you can't fix a problem you can't see.
Unreal gives you a built-in dashboard of live performance numbers, and getting at them is a one-key trick. In this lesson you'll open the console, put a frame-rate counter on screen, and — most importantly — learn to tell whether your computer's processor (the CPU) or its graphics card (the GPU) is the part holding you back. That single answer decides what you should optimise first. We'll finish with the Engine Scalability settings and a couple of honest, beginner-safe tips. No magic numbers, no guesswork — just measuring before you touch anything.
The vocabulary you'll keep meeting
Tap a card to flip it
Put your real numbers on screen
Press Play (or Alt+P) to start your level, then follow along. Each stat command is a toggle: type it once to show the overlay, type the same command again to hide it. Tick each step as you go.
- 1Open the console
With the game running in the viewport, press the backtick key (`). A console text bar appears, usually along the bottom or top of the play window.
This is where you type commands. You don't need to remember exact spelling — as you type, Unreal suggests matching commands you can click.
TipIf the backtick does nothing, click once inside the running game window so it has keyboard focus, then try again.
- 2Show the frame rate with stat fps
Type stat fps and press Enter. A small overlay appears showing your current frames per second and how many milliseconds each frame is taking.
Watch it as you move around. The number will rise and fall depending on what's on screen — that's normal. You're looking for where it drops, not a single perfect figure.
TipRun the same command again — stat fps — to turn the overlay off. Every stat command works this way as an on/off toggle.
- 3See the breakdown with stat unit
Type stat unit and press Enter. This is the most useful one. It shows several timings side by side: Frame (the total), Game (your CPU/gameplay time), Draw (the CPU time spent preparing what to render), and GPU (the graphics card's time).
All numbers are in milliseconds — lower is better. The key habit: look at which of Game, Draw and GPU is the biggest. That's your bottleneck.
TipFrame time roughly tracks the largest of the others, because the slowest part gates the frame. If Game is the biggest number, you're CPU-bound; if GPU is biggest, you're GPU-bound.
- 4Dig into the CPU side with stat game
If Game was your biggest number, type stat game. This expands the CPU/gameplay time into categories so you can see what's eating it — ticking actors, your Blueprint logic, physics and so on.
You don't need to understand every line. You're scanning for one or two rows that are far larger than the rest — those point at what to investigate.
Tipstat game shows a lot at once. Read it like a leaderboard: ignore the small entries and chase the one big one.
- 5Dig into the graphics side with stat GPU
If GPU was your biggest number, type stat GPU. This breaks the graphics card's frame time into passes — things like lighting, shadows, post-processing and translucency.
Again, look for the single largest pass. If, say, shadows or a post-process effect dominates, that's your clue about where the cost is coming from.
TipGPU cost usually rises with screen resolution and visual quality, so this is the side most affected by the Scalability settings you'll meet next.
- 6Close everything down
Toggle each overlay back off by retyping its command, or just stop playing. Stat overlays only show while you're testing — they don't appear in a shipped build unless you deliberately enable them.
Make a habit of glancing at stat unit whenever something feels slow. Measuring takes ten seconds and saves you hours of guessing.
The commands, in one place
stat fps ; live frames-per-second + total frame time
stat unit ; the big one: Frame / Game / Draw / GPU side by side
stat game ; expand the CPU 'Game' time into gameplay categories
stat GPU ; expand the graphics-card time into render passes
stat none ; clear all on-screen stat overlays at oncestat unit shows GPU as your biggest number by far. Should you go and optimise your Blueprints?
No. A big GPU number means you're GPU-bound — the graphics card is the part doing the longest work each frame. Optimising Blueprints (which run on the CPU's Game thread) won't help your speed limit at all; you'd be tuning the part that already has time to spare.
When GPU-bound, look at visual cost instead: resolution, lighting and shadow quality, post-processing, and overly detailed materials. The Engine Scalability settings are the fastest way to dial those down and confirm the GPU is really the culprit — if lowering quality jumps your FPS up, you've found your bottleneck.
Engine Scalability: the quality dial
Unreal groups its heavy visual features — things like shadows, global illumination, reflections, view distance, anti-aliasing and post-processing — into a set of quality levels you can change all at once. This is the Engine Scalability menu, and it's both a player-facing setting (Low to Epic, or Cinematic) and your single fastest diagnostic tool.
Find it from the editor's Settings dropdown in the main toolbar — open 'Engine Scalability Settings' and you'll get sliders for each group plus quick presets. Drop everything to Low, play, and watch stat unit: if your GPU time falls off a cliff and FPS shoots up, you were GPU-bound and now you know which features cost the most. Then nudge individual groups back up until you find the balance of looks and speed you're happy with. It's a deliberately reversible experiment, so it's a safe place for a beginner to start.
CPU-bound vs GPU-bound: where to look first
Your gameplay/logic thread is the limit. Common beginner causes: too many actors all ticking every frame, expensive Blueprint logic running on Tick instead of on events, and a high draw-call count from many separate objects.
First moves: use stat game to find the heavy category, turn off Tick on actors that don't need it, move work out of Event Tick into one-off events, and reduce the number of distinct objects on screen. Changing visual quality won't help much here.
Your graphics card is the limit. Common beginner causes: very high resolution, expensive lighting and shadows, heavy post-process effects, and lots of large overlapping translucent surfaces.
First moves: lower the Engine Scalability quality groups (especially Shadows, Global Illumination/Lumen, Post Processing and Effects), reduce screen resolution, and simplify materials. Use stat GPU to confirm which render pass is the costliest before you change anything.
QuizCheck yourself
1Which single command gives you the Frame / Game / Draw / GPU breakdown to find your bottleneck?
stat unit shows the per-frame timings side by side. The biggest of Game, Draw and GPU is your bottleneck — the part worth optimising first.
2In stat unit, the 'Game' number is by far the largest. What does that tell you?
Game time is the CPU's gameplay/logic work. When it dominates you're CPU-bound, so investigate ticking actors and Blueprint logic — not visual quality.
3What is a draw call, and why does it matter to a beginner?
Each draw call is CPU work to tell the GPU to render something. Scenes built from lots of separate small objects rack up draw calls and can make you CPU-bound.
Open any level you've built. Play it, press the backtick key, and turn on stat unit. Write down the Frame, Game, Draw and GPU numbers. Decide: are you CPU-bound or GPU-bound? Then open Engine Scalability, drop everything to Low, play again, and compare the same four numbers.
Hint 1
Backtick (`) opens the console; type stat unit and press Enter. Retype it to toggle off.
Hint 2
The biggest of Game, Draw and GPU is your bottleneck. Game biggest = CPU-bound; GPU biggest = GPU-bound.
Hint 3
Engine Scalability lives under the editor's Settings dropdown in the main toolbar; pick the Low preset, then play and re-read stat unit.
Hint 4
Compare like with like — look at the same spot in your level both times, since the numbers change with what's on screen.
Press Play, press `, type stat unit, Enter. Suppose GPU is clearly the largest number — you're GPU-bound. Open Settings → Engine Scalability Settings, choose the Low preset, then Play again and re-read stat unit at the same spot.
If the GPU number drops a lot and your FPS climbs, you've confirmed the bottleneck: graphics quality was the cost. Now you can raise individual groups back up one at a time to find a balance you like. If lowering quality barely changed anything, you were probably CPU-bound after all — switch to stat game and chase the biggest gameplay category instead.
The win here isn't the specific numbers — it's the method: measure, change one thing, measure again, and let the data tell you what to do.
You can now
Tick off what you've got under your belt:
- Open and close the Unreal console with the backtick key
- Show your frame rate with stat fps and the full breakdown with stat unit
- Tell whether you're CPU-bound (Game biggest) or GPU-bound (GPU biggest)
- Drill into the heavy side with stat game or stat GPU
- Use Engine Scalability to confirm a GPU bottleneck and dial quality up or down
- Optimise the honest way: measure, change one thing, measure again
Keys worth keeping
- ` Open / close the Unreal console (the key above Tab, shared with ~)
- Alt P Start Play-In-Editor to begin testing
- Esc Stop playing and return to editing
Mark this lesson complete
We'll remember it on your Academy page and unlock the next lesson below.
Questions beginners ask
My backtick key doesn't open the console — what's wrong?
Two common causes. First, the game window probably doesn't have keyboard focus: click once inside it, then press the backtick. Second, on some non-US keyboard layouts the key in that position isn't a backtick; you can rebind the console key under Project Settings → Engine → Input → Console Keys, or use the tilde (~) which is often mapped too.
What's the difference between being 'CPU-bound' and 'GPU-bound'?
Each frame, the CPU does gameplay and rendering-preparation work while the GPU draws the image. Whichever takes longer sets your frame time — that's your bottleneck. If the 'Game' line in stat unit is biggest you're CPU-bound (look at logic, ticking actors and draw calls); if 'GPU' is biggest you're GPU-bound (look at resolution, lighting, shadows and post-processing). Optimising the part that already has time to spare won't speed you up.
Should I just lower the Engine Scalability to make everything faster?
It's the fastest way to test whether you're GPU-bound, and it's a legitimate option to give players on weaker machines. But it only helps GPU-bound problems — if your CPU/Game thread is the limit, dropping visual quality changes little. Always check stat unit first so you're treating the real bottleneck rather than the easiest dial to reach.
Do I need to optimise this early in learning?
Not heavily. While you're learning, build first and worry about speed when something actually feels slow. What's worth doing from day one is the habit in this lesson: glance at stat unit when performance dips so you understand what's happening, rather than developing a fear of it. Knowing how to measure is more valuable than memorising fixes.