Browser performance · 3 min read
Browser Performance Budgets for 3D Web Experiences
Plan a browser 3D performance budget around texture memory, draw calls, loading and real devices. Lessons from Twined's After Hours web experience.
A browser 3D performance budget is a set of practical limits that helps a team decide what a scene can afford. It connects the visual ambition to the devices visitors actually use. Without it, optimization can become a late attempt to remove details from a design that depends on them.
There is no single safe polygon count or texture size for every WebGL experience. Devices, screen resolution, materials and scene behavior interact. Start with a representative phone and desktop, a small test scene and a visitor route that includes the busiest view. Use those observations to set initial limits.
Separate the costs you are measuring
Download size affects how long someone waits for the assets. Texture memory affects what must fit on the graphics hardware once those files are used. A small compressed image file does not automatically mean a small in-memory texture. Treat transfer size and runtime memory as separate questions.
Draw calls, shadows, transparency and screen resolution affect rendering work. Movement, collisions, interface updates and other JavaScript can consume time each frame too. Record the important costs independently so a slow camera turn is not automatically blamed on the model's polygon count. Measure a change before deciding that it helped.
Spend detail where the visitor can see it
Inspect the actual viewpoints. A distant roof, a small prop and a character close to the camera do not need the same detail. Prepare appropriate assets, avoid loading unrelated locations at the beginning and consider what can be reused. Keep enough headroom for a busier view and for the interface around the scene.
After Hours uses separate mobile settings and starts the 3D loading path when a visitor chooses exploration. Its touch movement uses a floating joystick, while desktop visitors can use keyboard controls. These are implementation choices in a self-initiated project, not a promise that the same settings will suit every scene or phone.
Test the journey, not just the opening frame
A scene can look smooth while stationary and struggle as soon as someone moves. Walk from the start to a busy destination, turn the camera, open an interaction and return. Repeat after visiting another location. Check whether assets accumulate, controls remain responsive and leaving the experience releases work that is no longer needed.
Include fresh loads and repeat visits, actual mobile devices, and reduced settings where needed. A desktop browser's narrow viewport is useful for layout checks but does not reproduce a phone's graphics hardware or memory limits. Keep the ordinary website available when exploration cannot start.
Write the agreed limits and test route into the brief. When a new feature exceeds them, decide whether to simplify it, defer it or adjust the supported experience. A performance budget is useful because it makes that tradeoff explicit while the design can still change.