Optimization Guide

Optimization is not only about making numbers smaller. In VRChat, optimization protects usability, social comfort, publish readiness, and repeat visits. This overview helps you decide what to measure first, what to fix first, and which deeper checklist to open next.

Recommended Setup

Use optimization as a planning habit, not just a cleanup pass after the world feels finished.

Measure spawn, the main social area, and the worst visible view before changing assets.
Fix the biggest rendering, lighting, material, and mirror costs before tiny cleanup items.
Retest with players, avatars, media, and platform targets that match real use.

VRChat note

In VRChat, performance problems become social problems. Heavy worlds can hurt comfort, reduce repeat visits, and block Quest or Android access.

What optimization actually protects

Good optimization helps preserve:

smooth movement and comfort
clear audio and readable interaction spaces
social usability under realistic player counts
cross-platform access for Quest or Android users
a cleaner upload and publishing path

Measure Before You Optimize

Start with the places players actually experience:

Area	What To Check
Spawn	First-frame comfort, visible geometry, lighting, mirrors, audio, and avatar crowd tolerance.
Main social space	The view most players will stare at for the longest time.
Worst-case angle	The direction that sees the most geometry, transparency, lights, videos, or mirrors at once.
Android or Quest build	Compressed size, texture memory, shader compatibility, readability, and actual device performance.
Multiplayer test	Avatar load, networking, pickups, mirrors, video players, audio, and synced systems under real use.

Use Unity's Profiler, Stats window, Frame Debugger, SDK build output, and actual VRChat test uploads together. One tool rarely tells the whole story.

Fix the biggest performance risks first

Most VRChat world performance issues come from a few repeated sources:

too much visible geometry
too many materials and large textures
heavy shaders and transparency
expensive mirrors and media systems
poor lighting decisions
Udon or networking logic that syncs more than it needs to
worlds tested alone instead of under real multiplayer conditions

Quick Priority Guide

Symptom	Start Here
Bad framerate at spawn	Reduce visible geometry, expensive shaders, lights, mirrors, and always-active effects near spawn.
World feels fine alone but bad with people	Test with realistic avatars, players, pickups, audio, video, and synced systems.
Draw calls or batches are high	Reduce material slots, atlas logical prop groups, and check whether shared materials actually batch.
Android build is too large	Reduce texture sizes, audio/video footprint, unused assets, and build-only PC content.
Android or Quest build runs badly	Prefer baked lighting, simpler shaders, modest textures, fewer transparent effects, and direct device testing.
Networked objects feel delayed or unstable	Use synced variables for persistent state, events for temporary actions, and avoid unnecessary ownership churn.

Recommended optimization route

Design the world clearly first with World Building.
Measure spawn, main social zones, and worst-case views.
Optimize materials, texture memory, lighting, occlusion, and heavy visible geometry.
Review mirrors, video players, animated effects, particles, and Udon networking.
Test with actual players, realistic avatars, and the target platforms.
Recheck upload readiness before publish or Community Labs submission.

Platform Planning

PC-only worlds can usually afford richer materials and larger textures, but they still need to run well with real avatars and players. Android and Quest versions need a stricter plan from the beginning: simpler shaders, baked lighting, modest textures, fewer transparent surfaces, and direct testing on the Android build.

VRChat's Android guidance treats Quest-related SDK language as generally relevant to Android too, so do not think of mobile support as a late export button. If cross-platform access matters, plan it while the world layout, art style, and material count are still easy to change.

Key pages to use with this guide

Core optimization references

Useful supporting topics

Optimization mindset

The best optimization choices usually happen before a world becomes difficult to change. If you wait until the whole scene is packed with detail, materials, effects, and interactive systems, every cleanup becomes more expensive.

That is why this guide works best as a planning page, not only as a repair page.

Help! I do not know what to optimize first.

Start with measurement, then fix the largest visible costs: spawn geometry, materials, texture memory, lighting, mirrors, video players, shaders, transparency, and busy social areas.

Help! My world only lags with people inside.

Test with realistic avatars and player counts. Multiplayer sessions reveal costs that solo editor testing cannot show.

Help! I want Quest support later.

Plan mobile budgets now. Quest and Android support are much harder when the finished PC scene already depends on heavy shaders, large textures, transparency, and expensive effects.

Help! My optimization pass made editing harder.

Back up source assets and avoid merging unrelated scene sections. Good optimization should reduce runtime cost without destroying your ability to light, cull, update, or debug the world.

Help! My Udon systems are causing spikes.

Sync only state that needs to persist for other players or late joiners, use events for temporary actions, and avoid frequent ownership swaps or unnecessary networked rigidbodies.