Why your Unreal Engine 5 scene is slower than it should be
Short answer: most slow scenes are not one mystery cost. They are a few repeated asset decisions multiplied across a level. Start with geometry that never gets cheaper, expensive shadow casters, texture-memory pressure and draw-call count—in that order as a useful first pass, not a universal law. Measure before and after every change.
First decide which frame you are fixing
At 60 fps the whole frame has 16.67 ms. At 30 fps it has 33.33 ms. The slower of the game thread, render thread and GPU determines the frame. Cutting two milliseconds from the GPU does not help a frame that is blocked for six milliseconds longer on the game thread.
stat unit stat gpu stat scenerendering stat streaming profilegpu
Run these in a representative camera path, on the hardware you care about, with the same scalability settings you intend to ship. An editor viewport is useful for comparison, but it is not a substitute for a packaged build when the numbers matter.
1. Geometry that never gets cheaper
A conventional static mesh without useful LODs keeps submitting its most detailed geometry after that detail is smaller than a pixel. The waste is multiplied by every visible instance. Nanite changes the geometry pipeline, but it does not make every mesh or every instance free; the next guide covers that boundary.
Look for meshes with one LOD, weak reduction between LODs, or screen-size thresholds that keep LOD0 visible too far away. Check the assets that repeat across the scene before the one hero mesh standing next to the camera. Ten thousand medium-cost props can matter more than one expensive prop.
2. Shadow casters that repeat the work
A shadow-casting light asks visible geometry to do additional work for the shadow map or virtual shadow-map pages. A movable light covering a large area can make the same foliage, modular kit and character geometry appear in several passes. The expensive object is not always the light with the highest intensity; it is often the light whose influence and caster set are largest.
Disable shadow casting on objects whose shadows cannot be read, tighten light influence, and test whether a light must be movable. Do not remove shadows globally to make a capture green. Change one caster group or light at a time and compare the shadow pass in profilegpu.
3. Texture memory before texture sharpness
Texture memory is not a single frame-time counter. Pressure appears as streaming churn, bandwidth use, pool over-budget warnings and hitches when higher mips move in. A scene may hold its target frame rate while the camera is still, then hitch as soon as it turns.
Check dimensions, compression, mip generation and residency together. A 4K texture is not automatically wrong, and a 1K texture is not automatically cheap if hundreds of unique textures must remain resident. The useful question is whether the visible result needs the mip data being kept for the target camera distance.
4. Draw calls when the CPU is preparing too much work
Each draw call carries CPU-side submission and state work before the GPU shades a pixel. Material slots, separate mesh sections, translucency and many unique state combinations can split what looks like one object into several draws. Instancing and merging can help, but merging everything can damage culling and streaming. The correct batch size depends on how the level is seen.
Why a profiler shows the symptom, not the asset
Unreal Insights and the GPU Visualizer are good at telling you where time went: a render pass, a thread, a task or a marker. They often cannot tell you which source asset decision caused that pass to become expensive. A large shadow pass may contain thousands of casters. A render-thread spike may be many small submissions rather than one obvious actor.
That is where an asset audit can complement a profiler. A tool such as Framegain can rank static facts like missing LODs or costly configuration, but it cannot replace a runtime capture. The audit names candidates; the profiler tells you whether changing them moved the frame.
Why “optimise everything” is the wrong strategy
Every optimisation has a cost: artist time, visual quality, build complexity, memory, or reduced flexibility later. Changing assets that are off-screen, already cheap, or outside the bottleneck adds risk without buying frame time. It also makes the next measurement harder because too many variables changed at once.
A useful loop is: identify the limiting thread, rank a small set of likely causes, change one class of asset, reproduce the same capture, and keep the change only if the target metric moves. Stop when the frame meets budget. A quieter profiler is not the goal; a stable frame on target hardware is.