Unity Performance Budgets: How to Set Frame-Time Targets Your Game Actually Hits

Every frame of your game has a deadline. At 60 FPS that deadline is 16.6 milliseconds; at 90 FPS in VR it’s 11.1. Miss it and the player sees a hitch, the headset judders, or the phone starts to cook. A performance budget is simply the decision, made early, about how those milliseconds get spent — and it’s the single most effective thing you can do to avoid the “why is my game running at 20 FPS” panic three weeks before launch.

What a Performance Budget Actually Is

The math is trivial: budget in ms = 1000 ÷ target FPS. The discipline is in what you do with the result. A budget turns “make it fast” into a set of concrete limits you can check against every week:

• Frame-time budget — the hard ceiling. 33.3 ms at 30 FPS, 16.6 ms at 60, 11.1 ms at 90, 6.9 ms at 144.
• Sub-budgets — how that time is split between rendering, gameplay code, physics, animation, UI, and audio.
• Resource ceilings — draw calls, triangles on screen, texture memory, active rigidbodies, particle counts. These aren’t time directly, but they’re the levers that move it.
• Headroom — the slice you deliberately don’t spend, so the game survives a busy scene, a mid-range device, or thermal throttling.

Studios that ship on consoles have done this for decades because certification forces them to. Indie and mobile teams usually skip it, then rediscover the concept the hard way during optimization crunch.

Step 1: Pick the Target Frame Rate Honestly

The target depends on the platform and the genre, and it should be a decision, not a hope.

Platform	Typical target	Budget
Mobile (casual, puzzle, strategy)	30 FPS	33.3 ms
Mobile (action, racing, shooters)	60 FPS	16.6 ms
PC / console	60 FPS	16.6 ms
PC competitive / high-refresh	120–144 FPS	8.3–6.9 ms
VR (PC or standalone)	Headset native: 72, 90, or 120 Hz	13.9 / 11.1 / 8.3 ms

Two rules of thumb. First, mobile 60 FPS costs far more than double 30 FPS once thermal throttling kicks in — a phone that hits 60 for two minutes and then drops to 40 feels worse than a locked 30. Second, VR is not negotiable: dropping below the headset’s refresh rate causes discomfort, not just a visual stutter, so budget for the native rate with real headroom.

Step 2: Split the Budget Between CPU and GPU

This is the part most guides skip. The CPU and GPU work in parallel, so your frame time is the longer of the two, not the sum — but each one has to fit inside the budget on its own. A useful starting split for a 16.6 ms budget looks like this:

Slice	Rough allocation	What lives here
Rendering (CPU side)	4–5 ms	Culling, batching, draw-call submission, SRP overhead
Gameplay scripts	3–4 ms	Your Update() code, AI, input, state machines
Physics	2–3 ms	FixedUpdate, collision, raycasts
Animation & UI	1–2 ms	Animator evaluation, Canvas rebuilds, layout
Audio, particles, misc	1 ms	Mixer, particle simulation, garbage collection spikes
Headroom	2–3 ms	Unspent on purpose

On the GPU side the budget is consumed by fill rate (how many pixels you shade, including overdraw), shader complexity, shadow maps, and post-processing. Mobile GPUs are almost always fill-rate bound; desktop GPUs are more often limited by shadow passes and expensive post effects.

Step 3: Translate Time Into Resource Ceilings

Milliseconds are what you measure; draw calls and triangle counts are what you can actually control while building content. Give your artists and level designers numbers, not adjectives. For a typical URP project the starting points look like this — the calculator has the full per-platform tables:

• Mobile at 30 FPS: ~100–150 draw calls, 150–300K triangles on screen, 256–512 MB of texture memory, one real-time shadow-casting light at most.
• PC / console at 60 FPS: ~500–2000 draw calls, 1–5M triangles, 1–4 GB of texture memory, two to four shadow-casting lights.
• VR at 90 FPS: ~100–200 draw calls per eye, 500K–1M triangles per eye, and bake everything you possibly can.

Draw calls deserve special attention on mobile. The GPU can often push more triangles than you’d expect, but every draw call costs CPU time to submit, and mobile CPUs are slow. That’s why static batching, GPU instancing, and the SRP Batcher matter more than shaving polygons on most phone games.

Step 4: Measure on the Real Target, Constantly

The Unity Editor lies about performance. It runs on your development machine, it carries editor-only overhead, and it never throttles. Your budget only means something when measured on the weakest device you intend to support.

• Profiler (Ctrl+7): connect it to a development build running on the device. The CPU module shows you exactly which slice of the budget is over.
• Frame Debugger: steps through every draw call in a frame so you can see what’s breaking batching and which passes are expensive.
• Profile Analyzer (Package Manager): compares two captures so you can prove a change helped rather than guess.
• Memory Profiler: for the texture-memory ceiling, which the frame-time view won’t show you until it’s already causing hitches.

Make profiling a habit, not an event. A weekly capture of your heaviest scene on your minimum-spec device catches regressions while they’re one commit old instead of two hundred.

Where Budgets Go Wrong

• Profiling only the empty scene. Budgets are for the worst case: the boss fight with thirty enemies and every particle effect at once.
• Forgetting garbage collection. Per-frame allocations (string concatenation, LINQ in Update(), GetComponent in loops) don’t show up as steady cost — they show up as periodic 5–20 ms spikes that blow the budget every few seconds.
• Spending the headroom. The 2–3 ms you reserved is not free real estate for one more effect. It’s what keeps the game smooth on the device you didn’t test on.
• Treating the numbers as law. The ceilings are starting points. A stylized game with flat shaders can afford far more triangles than one with layered PBR materials. Adjust once you have real captures.

Bake It Into the Project

A budget nobody can see is a budget nobody follows. Put the targets in the project README, add them to your pre-ship settings checklist, and set Application.targetFrameRate explicitly in code so the whole team is testing against the same ceiling. If you’re building for WebGL, remember the download is a budget too — our WebGL Build Size Estimator covers that side.

Start with the calculator’s numbers, measure on-device in week one, and adjust. The goal isn’t to hit a magic figure — it’s to never be surprised by your own frame rate again.