Why Optimising Isn’t A One-Size-Fits-All
High-Level Flow For Optimising
Common Approaches To Optimisation
Build Smarter Pipelines To Catch Issues Early
Practical Advice for Staying Optimised
Tools and Console Commands Every UE Dev Should Know
Smaller Bugs and Mis-optimisations Add Up
Tools I Built to Help (Project Optimise | Level Optimise)
Closing Thoughts

Let’s dive into it!

Why Optimising Isn’t A One-Size-Fits-All

When it comes to optimising your Unreal Engine project, it’s easy to feel overwhelmed, especially if you are new to it all. It can be hard to know where to start, what actually matters, and how deep to go.

There are loads of resources out there, but the truth is: optimisation is highly contextual. What works for one project might be wrong for another. It depends on loads of factors: visuals vs performance, your team size, your experience level, the scope of your game, which platform you will release on, game genre, how much time you’ve got, etc. It’s complicated, there is no clean, one-size-fits-all checklist.

So, rather than giving you a rigid step-by-step guide, I wanted this blog post to share some of the insights I’ve learnt over the last 10+ years making games in the Unreal Engine. Instead, offering more of an overview-style approach. Think of it as a set of tools, ideas, and mental models you can use to figure out what your project actually needs.

High-Level Flow for Optimising

One of the challenges I faced when first learning how to optimise my projects was simply not knowing how to approach it. But over the years, I’ve built a reliable approach that avoids randomly tweaking things and instead follows a logical, testable loop. It helps keep your changes focused on things that actually make a difference.

1. Define the Problem

Start by making observations so you can define the problem, e.g. “The forest level runs worse than others”. Ask yourself things like:

Is the game running slowly?
Are there noticeable frame drops or hitches?
Which level or situation causes the issue?

2. Form a Hypothesis

Ask yourself, Why might this be slow? Remember to start simple. For example:

There’s too much foliage on screen?
Those VFX explosions are too heavy?
Is this blueprint doing too much work?

3. Investigate

Use commands like Stat Unit, Stat Graph, and tools like Map Check, Unreal Insights or the GPU Visualiser to gather data and dig deeper into what supports (or disproves) your hypothesis. If you’re newer to optimisation, this is the point where it helps to lean on Google, the Unreal Forums, or even ChatGPT to better understand the issue. The good news is: because you’ve already formed a targeted hypothesis, your searches become much easier and more focused. Instead of “Why is my game slow?, you’re asking “How can I tell if foliage needs optimising?” Here are a couple of useful things to investigate during this stage:

Is the CPU or GPU struggling?
Which part of the frame is expensive?
Which assets or actors are involved?

4. Make a Targeted Change

Once you think you’ve found a likely culprit, make one specific change based on your hypothesis (one variable at a time means you can clearly see what effect it has). Just like before, targeted research can help here too, as we can focus in on the solution. For example:
“How to improve foliage performance in UE5”. Some common things you might find yourself tweaking are:

Reducing complexity
Adding LODs
Disabling tick
Enabling/Disabling Nanite
Culling unnecessary objects

5. Test Again

Now, playtest under the same conditions: Same camera angle, same number of A.I, same part of the level, etc. Here you’re checking to see if the change actually made a difference. Ask yourself things like:

Has the frame rate improved?
Did the hitch or stutter disappear?
Did GPU, CPU or draw calls go down?

If YES - Good job. If NO - No stress, go back to your hypothesis and try a different angle

6. Repeat as Needed

Rinse and repeat, optimisation is iterative. You won’t fix everything in one pass, and that’s okay. Focus on the biggest wins first. The stuff that actually impacts performance and player experience. You can always come back later for fine-tuning once the major issues are resolved.

Avoid the temptation to over-optimise too early. For example, spending hours squeezing 0.2ms out of a material won’t matter if you’ve still got ten tick-heavy Blueprints tanking your frame rate or you haven’t finished key mechanics for your game’s core loop. Fix what matters now:

Save the polish for later
Stay focused on what gives you real, measurable improvements

Over time, your project will get faster and more stable. But more importantly, you’ll gain valuable experience. Learning do’s and don’ts that you can incorporate into your everyday workflows, removing the need for a certain level of optimisation in the future. For example, you’ll start avoiding Tick in Blueprints by default, instead leaning on event-driven functionality where possible.

Common Approaches To Optimisation

I’ve seen (and tried) a lot of different approaches to fixing bugs and performance problems. There is no single “right” method, and a lot of it depends on things like your team size, skill level, project scope, the complexity of the issue, and your deadlines.

Take a AAA studio with over 100 developers and a solo dev working evenings and weekends. They’re going to approach optimisation very differently. What’s practical (or even possible) for one won’t necessarily work for the other.

That said, I think most developers end up falling into one of two broad camps. Here are the two main approaches I’ve seen, along with some pros and cons from my own experience:

Constantly Optimising

You're always checking stats, always tweaking, aiming to fix bugs and unoptimised content as soon as they pop up.

Pros:

Keeps things tidy and performant throughout development
Fewer surprises (and less panic) near shipping

Cons:

Time-consuming and can slow momentum
Can lead to over-polishing things that may later change or be cut
Relies on team size/budget. So less realistic for solo devs or teams with tight timelines

Periodically Optimising

You focus on building first, and leave most of the optimisation until later, usually at the end of a milestone or right before shipping.

Pros:

Lets you focus on creativity and iteration during the bulk of development
Less time wasted optimising things that might get cut or changed later
Good fit for small teams or solo devs juggling multiple responsibilities

Cons:

Issues can stack up fast, turning into a massive task near the end of development
Harder to track down the root cause of certain problems
The final optimisation sprint can be stressful and overwhelming
Risk of only uncovering major problems you weren’t expecting late in development

The Goldilocks Zone – A Mix of Both

Personally, I’ve found that for solo projects or small teams, the most effective approach is a hybrid between constantly and periodically optimising. Here’s the general approach I take:

Check performance regularly - Especially after adding bigger new features
However, don’t go too deep every time - Just keep an eye out for and fix up major FPS drops, hitches/stutters or obvious red flags
Go deeper as you begin approaching deadlines for milestones, sprint ends, or key events. Put a bigger focus on fixing and optimising accumulated issues

This way, you avoid that final, stressful “last-minute optimisation sprint,” but also you don’t waste time over-polishing assets or systems that might change later. It’s all about finding that balance between momentum and maintainability.

Build Smarter Pipelines to Catch Issues Early

One thing that’s better than fixing optimisation problems is making sure those problems never exist in the first place. One of the best ways to do that is by building good pipelines that can reduce human error.

Think of it like brushing your teeth. Regular, low-effort habits/pipelines that stop you needing painful, expensive fixes later

Here are two examples I think are worth knowing about:

Interchange Feature (UE5.4+)

Here's a video from Unreal Engine on setting up Interchange presets

Added fairly recently, Interchange lets you set up import presets that can apply specific settings when bringing assets into the engine. This ensures consistent import settings across your project, eliminating human error. It’s especially useful on larger teams where not everyone importing assets might know the “correct” settings. I use this to define import settings for different asset types, like: Skeletal mesh imports, Animation imports, Static mesh imports.

Asset Validators

Here is a YouTube video from creator ‘Z-Axis Up’ on setting up blueprint asset validators

Another great preventative tool is asset validation. You can setup and run validators to catch potential issues like:

Non-power-of-two textures
Assets missing LODs

If you're using source control, you can even integrate validators as pre-commit scripts (with a bit of extra setup). These can automatically scan assets before they're submitted to your repo, helping catch mistakes early in your pipeline. Just remember: context matters. A non-power-of-two texture might be a red flag… unless it’s a UI texture that needs to be that size.

Practical Advice for Staying Optimised

As I mentioned above, context is key when it comes to optimisation. However, there are patterns and good habits you can use as a starting point. Below are some general guidelines for trying to keep things optimised across the main asset types. Always test performance in your actual game context to make sure it works for your project.

Static Meshes

Enable Nanite where appropriate - Nanite isn’t always better. When I wrote this, it should generally be avoided on small assets, meshes with vertex deformation, and things using translucent materials, as Nanite doesn’t support. Do your research and test in your context.
Disable unnecessary collision and shadows - E.g. you could consider turning off collision on actors outside the player’s reachable area

Skeletal Meshes

Make sure you have skeletal mesh LODs setup

Materials

Avoid overly complex shader graphs, especially for translucent materials
Use Material Instances instead of duplicating base materials

Textures

Keep texture resolutions reasonable - E.g. don’t use 8k textures unless you have a really good reason
Keep an eye out for duplicate textures in your project - Sometimes, content packs will use identical textures
Use compressed formats when possible - Requires power-of-2 sizes, so plan ahead

Blueprints

Try to break up large, monolithic blueprints into smaller, more modular pieces
Try to use the fewest number of components for what you’re trying to do - e.g. static mesh component or skeletal mesh component
Disable Tick wherever possible - Replace it with event-driven logic: overlap events, timers and custom events instead

Lights

Set a Max Draw Distance on lights
Disable Cast Shadows if they aren’t needed or don’t add anything to the visual feel
Try to use Static or Stationary movement mode for lights where possible

VFX / Niagara

Limit the number of GPU particles where possible
Use LOD and culling settings - To keep systems lightweight when off-screen or at a distance
Be mindful of translucent particle stacking - It adds up fast and can destroy GPU performance

Foliage

Make sure you have LODs and culling distances set

Audio

Make sure you have sound concurrency rules in place - This lets you limit the number of sounds able to play at one time (can be world or actor limits)

Tools and Console Commands Every UE Dev Should Know

Here’s a shortlist of powerful commands and tools that you should know about when optimising:

Commands:

Stat FPS - Shows the current FPS value
Stat Unit - Show frame time, game thread, render thread
Stat UnitGraph - Display real-time performance graphs for frame timing
dumpticks - Outputs a list of all ticking actors and their tick groups to your output log
MemReport - Generate a memory usage snapshot and save it to your project logs
freezerendering - Freeze the rendering thread for static performance capture
r.ScreenPercentage X - Set screen resolution scale. Replace X with a value you want e.g. 50 = 50% of native resolution. Lowering the screen percentage reduces GPU load, which can help you confirm if your project is GPU-bound (if performance improves noticeably, it’s likely GPU-related)

Tools:

Map Check - Scans your level for common issues like missing references, invalid lightmaps, or unused actors. Great for catching obvious problems quickly
Viewmodes - You can toggle useful visual debugging viewmodes like Shader Complexity, Player Collision, Light Complexity, etc., great for helping you narrow down issues
GPU Visualizer - Opens a detailed breakdown of GPU rendering cost per pass. Helps you understand where GPU time is going (e.g. BasePass, Shadows, Translucency). Check out how it works here

Small Bugs and Mis-optimisations Add Up

Even with good intentions and solid pipelines, you’ll still get issues. Over the years I’ve been making games, I’ve seen that while you do get larger performance killers, it’s also the case that small bugs and little mis-optimisations will make their way into your project, building up over time.

These little issues accumulate and snowball into something much bigger. And with enough of them, they can negatively impact a player's perception of your game almost as much as a single, larger bug could. This results in what I like to call:

Death By A Thousand Bugs

A few unoptimised lights here, a skeletal mesh with no LODs there, a rogue 8K texture from a marketplace pack… etc

By their very nature, these smaller issues are time-consuming and tedious to find. Manually checking every actor and asset in a large project just isn’t realistic. It becomes like searching for needles in a haystack. That’s exactly why I built a pair of tools to help quickly identify those needles (issues) in your project’s content and in your levels

Tools I Built to Help

Over the years, I’ve spent a lot of time trying to track down issues in projects I’ve worked on. That’s what led me to make my own tools, to help speed up the process of finding potential bugs and optimisation opportunities. I use them in my own projects to tackle real production challenges. Here’s a quick overview:

Project Optimise Tool

A project-wise, content-focused tool that takes a more holistic view of your Unreal Engine 5 project. Helping you weed out bugs and possible optimisations across your projects entire content library. I usually run this first, to reduce the overall number of issues in the project before diving into level-specific problems with my second tool.

Level Optimise Tool

A level-focused tool that helps identify potential bugs and optimisation opportunities in the actors placed in your Unreal Engine 5 level. It’s designed to help you claw back FPS by helping you find trouble makers like:

Lights with no Max Draw Distance set
Lights with Cast Shadows enabled
Static meshes with Nanite disabled
…and many more ways

CloSing thoughts

Optimisation can definitely feel overwhelming, especially when you’re deep into development, juggling bugs, builds and looming deadlines. But like anything in game dev, the more you do it, the more natural it becomes.

Just remember: it’s an ongoing process and when you feel lost or stuck, chances are someone else has already run into the same issue and shared something useful about it. There’s a ton of great info out there on the Unreal Forums, YouTube, Google, ChatGPT, and beyond.

Just like how hopefully, this post has given you some helpful insights, a few new tools to try, and fresh ideas to help you along the way.

You got this.

Contents