Comfort in VR depends on consistent performance, low latency and predictable interaction. A target such as 72, 80, 90 or 120 Hz depends on the headset, runtime and application configuration. The right goal is the supported refresh rate that the experience can sustain reliably on its target hardware.
Understand the frame budget
At 90 Hz, a frame has roughly 11.1 milliseconds to complete. At 72 Hz, the budget is about 13.9 milliseconds. These are total frame-time budgets, not goals to hit only in an empty test scene. Leave headroom for gameplay variation and system overhead.
Find the real bottleneck
Profile CPU and GPU separately. CPU pressure can come from scripts, physics, animation, draw-call submission and garbage collection. GPU pressure often comes from fill rate, shader complexity, shadows, overdraw, render scale and expensive post-processing.
Optimize the scene deliberately
Use appropriate level of detail, occlusion and frustum culling, efficient materials, texture compression and sensible lighting. Reduce unnecessary real-time shadows and transparent layers. Use batching or instancing where it fits the scene, and avoid adding complexity without measuring the result.
Test on the actual headset
Editor performance is not a reliable substitute for device testing. Profile representative gameplay on the target headset, include busy scenes and longer sessions, and monitor thermal behavior. Re-test after content, SDK or rendering changes.
Make optimization continuous
Establish performance budgets early and include them in code reviews and release checks. Record frame-time baselines, test repeatable scenarios and fix regressions before they reach players. Never advertise a guaranteed frame rate without validating it across the supported device and workload.
Every project has different constraints. Validate technical choices against the target devices, audience, budget and release plan rather than relying on a one-size-fits-all rule.