Rendering / 2026-05-13 / 9 min read
URP performance mistakes I look for first
The first rendering checks before we blame the engine, the GPU, or the phase of the moon.
Start with the obvious frame costs
URP performance problems often look mysterious because they arrive through many small, reasonable choices. Too many lights. Expensive transparent layers. Post-processing with ambitions. Shaders that were introduced to the target device very late in the relationship.
Before changing architecture, I look for the cheap truths. What is the target frame budget? Which passes are active? Are we paying for features the scene does not need, because a checkbox once seemed harmless?
Define the budget before the villain
A performance investigation without a budget is just complaining with graphs. The first question is boring: what are we trying to hit? 60 FPS gives you 16.6 ms. 72 FPS gives you 13.8 ms. 90 FPS gives you 11.1 ms. Mobile VR is less a rendering target and more a small courtroom where every millisecond testifies.
I split the budget into CPU main thread, render thread, GPU, memory, and loading or spikes. A frame can be slow because the GPU is overloaded, but it can also be slow because scripts are generating work, culling is expensive, batching is broken, or assets are arriving like luggage at a regional airport.
First capture, then opinion
I want one clean capture before changing anything. Unity Profiler, Frame Debugger, RenderDoc if needed, device-specific tooling when the target hardware matters. Editor numbers are useful for direction, not confession. The device is where the truth becomes less polite.
The capture should answer simple questions. How many draw calls? Which render passes exist? How much time is spent in shadows? Are transparent objects stacked like geological layers? Is post-processing eating the dessert before the frame has dinner?
Make the pipeline visible
The frame debugger, render graph view, GPU timings, and simple before-after captures usually tell the story faster than speculation. Speculation is fun, but the GPU does not respect vibes.
A good optimization pass removes uncertainty. It does not just make the frame faster; it leaves the team with a clearer model of why the frame was slow. The model is the part that keeps paying rent.
The usual suspects
The first suspects are rarely glamorous. Realtime shadows with generous cascades. Too many additional lights. Overdraw from particles, UI, foliage, glass, smoke, and other transparent optimism. Full-screen effects at full resolution. Materials that create more shader variants than the project can explain in public.
I also check render scale, MSAA, HDR, depth texture, opaque texture, camera stacking, renderer features, and anything that adds a pass because it sounded harmless in a meeting. URP is good at making features accessible. Accessibility is not the same as free.
Change one thing at a time
The fastest way to learn nothing is to change six settings and celebrate the improvement. Maybe the frame got faster. Maybe it got faster because the scene no longer renders half the content. A useful optimization change has a small diff and a measurement attached to it.
I keep a short log: what changed, why it was tried, what capture was used, CPU before and after, GPU before and after, visual cost, and whether the change is reversible. This is not bureaucracy. It is a memory prosthetic for a process that otherwise becomes folklore by lunch.
Prefer recoverable changes
The first fixes should be reversible and easy to explain: reduce overdraw, simplify materials, control shadow settings, split quality tiers, or move expensive effects behind explicit constraints. Heroic rewrites come later, if the numbers still demand tribute.
Recoverable changes also build trust with artists and designers. If a performance pass only says no, it becomes a tax. If it explains the budget and offers tiers, masks, distances, cheaper variants, or capture-backed tradeoffs, it becomes a tool.
What success looks like
A good URP performance pass ends with three things: a faster frame, a written explanation, and a short list of rules the project can keep following. Do not ship only the faster frame. Without the explanation, the project will politely grow the same problem back.
The best result is not a heroic rescue. It is a rendering setup boring enough to maintain. Boring is underrated. Boring reaches certification.