Unity Engineering · Jul 27, 2026
The 40-Point Unity Performance Checklist We Run Before Every Release
Most Unity performance problems are not discovered. They are shipped, and then reported by a player on a three-year-old Android device with 3GB of RAM. A checklist will not catch every regression, but it catches the ones that matter most, before a publisher or a one-star review does.
Here is the actual 40-item pass we run against every release build, grouped by system, before it goes anywhere near a store listing.
Rendering (Items 1-7)
- Profile with the Frame Debugger before touching a single shader – know what is actually drawing before you optimize it.
- Check SetPass call count against your target device’s realistic budget, not a flagship phone’s budget.
- Audit overdraw with the Scene view overdraw shading mode, especially on UI-heavy screens and particle-heavy VFX.
- Confirm static and dynamic batching are actually batching what you think they are – a single material or shader keyword variance silently breaks a batch.
- Verify texture compression settings per platform (ASTC for mobile, not a leftover default from a desktop build target).
- Check mipmap generation is enabled on anything that is not UI, and disabled on anything that is.
- Run an LOD pass on hero assets that appear in wide shots or zoomed-out gameplay cameras.
Memory (Items 8-15)
- Take a Memory Profiler snapshot on your lowest-spec target device, not the editor.
- Diff that snapshot against the previous release to catch creeping growth early.
- Confirm texture streaming budgets are set per device tier, not one global value.
- Check for duplicate asset references across Addressable groups or asset bundles.
- Pool anything instantiated repeatedly during play – projectiles, VFX, UI popups.
- Track native memory (audio, video) separately from the managed heap.
- Verify DontDestroyOnLoad objects are actually meant to persist, not leftover from a debug scene.
- Check for lingering event subscriptions that keep objects alive past their scene.
CPU and Scripting (Items 16-23)
- Profile a full session on-device with the Unity Profiler in Deep Profile mode at least once per release.
- Audit Update() calls and move anything that can be event-driven off the per-frame loop.
- Check GC alloc per frame – boxing, closures, and LINQ in hot paths are the usual offenders.
- Review coroutines running every frame against a plain Update loop for actual cost.
- Apply the Job System and Burst to any hot numeric loop that qualifies.
- Confirm physics tick rate is matched to gameplay needs, not left at the project default.
- Check for synchronous loading calls that block the main thread mid-gameplay.
- Profile UI layout rebuilds – unnecessary Canvas rebuilds are a common hidden cost.
Physics (Items 24-28)
- Confirm collision matrix layers are actually pruning the interactions you expect them to.
- Check rigidbody sleep thresholds so idle objects are not being simulated every frame.
- Review collider complexity on anything using mesh colliders where a primitive would do.
- Verify fixed timestep settings match the gameplay feel you are shipping, not a default value.
- Test physics behavior at low frame rates specifically – this is where desync bugs hide.
Build and Load Times (Items 29-34)
- Time cold start on your lowest-spec target device, not a development machine.
- Measure scene load times individually, not just total app launch time.
- Use async loading for anything that would otherwise block the main thread.
- Confirm IL2CPP and code stripping settings are correct for the release configuration.
- Break the build size down by category – textures, audio, code – not just one total number.
- Verify debug symbols are stripped from the release build specifically.
Device and QA Pass (Items 35-40)
- Test on the actual lowest-spec device in your target market, not the closest phone on someone’s desk.
- Run a 20+ minute continuous session to check for thermal throttling.
- Benchmark battery drain against a baseline session length.
- Confirm crash reporting is wired and verified with a deliberate test crash.
- Run the build through your full device matrix, not a shortlist of two or three phones.
- Re-run this entire checklist after any major dependency or Unity version upgrade.
Conclusion
None of these 40 checks are individually exotic. What actually moves the needle is running every one of them, on every release, on real target hardware, instead of trusting that a smooth demo means a smooth launch. That discipline is what turns “should run fine” into a frame-time number you can put in a contract.
Keep Reading
More from the blog
Want these insights on your build?
The engineers writing these articles are the ones who would work on your game.