Introduction to Optimizing for the Web

An overview of why developers should build for the web, how optimizing experiences for the web is different from native, and what characteristics define an optimized experience.

Why Build for the Web?

🌍 Reach millions of users instantly 🌍

An estimated 3 billion people have access to a 3D-capable web browser and high-speed internet connection⁰^,¹^,²^,³^,⁴. Millions of users play video games in the browser each month, providing a wide reach for your 3D experience.

🚀 Launch on any device with a 3D-compatible web browser 🚀

3D web apps reach phones, desktop computers, laptop computers, and mixed reality (XR) headsets via the same URL. The vast majority of internet activity happens in 3D-capable browsers (Chrome, Edge, Firefox, and Safari)⁵ running on 3D-capable operating systems (Android, iOS, OSX, Windows)⁶.

An estimated 99% of browsers in use support 3D experiences via the WebGL API⁷.

🔐 Secure by default 🔐

The web’s application sandbox, HTTPS, and permissions model let you consume powerful graphics, XR, and platform features with user consent and origin isolation.

🤝 The same standards for everyone 🤝

APIs and technologies like WebGL, WebGPU, WebXR, WebAssembly (WASM), CSS, and JavaScript are stewarded by mature standards bodies and implemented across major web browsers. There is no store gatekeeping compared to native platforms.

🪶 No download required 🪶

Web experiences do not require users to download an application ahead of time from a store, making it simple for new users to try out your experience and share it with friends.

What makes an experience well-optimized?

Developing for the web comes with many advantages, but developers must ensure that the experience performs well on many devices. What's more, there is a large variance of 3D performance within device classes; a mobile user could be on the latest iPhone or an older budget device. While developers instinctively know what an optimized experience feels like, it can be hard to describe. Here, we outline six characteristics that describe a well-optimized experience.

⚡ Fast-loading

Research shows that users are much more likely to return to applications that load quickly. In a well-optimized experience, users can expect to see a loading indicator in milliseconds and interact with the scene in seconds.

🪨 Stable

A stable scene produces new images at a consistent rate, regardless of frequency. When there are random gaps between new images, the user's immersion is broken, just like when a video buffers.

🫡 Responsive

In a responsive experience, the scene updates immediately in response to user inputs. Users expect the camera to track directly with inputs, and can even experience nausea if there is too much latency. Beyond the camera movement, users expect UI elements to respond to clicks and player animations to trigger on button presses. It is easy to break immersion when an experience is not responsive.

🌊 Fluid

Fluidity, or smoothness, is the characteristic that users typically associate with performance. Fluidity is defined by how a scene looks in motion; in a fluid scene, the user should not be able to perceive the gaps in time between each image, instead perceiving a continuous stream of imagery.

🔍 Legible

A scene may be smooth and stable, but this does not matter if individual elements in the scene cannot be interpreted. Users must be able to read all UI elements and identify models in motion. This characteristic is most related to screen and texture resolution. High aliasing, or blurriness, also reduces legibility.

📐 Scalable

Regardless of whether an experience runs in a mobile browser or desktop browser, users expect performance comparable to native applications on that platform. A scalable experience tunes its performance to the device it's running on.

Optimizing 3D experiences for the web vs native platforms

While the core principles of game development are universal, building on the web requires additional optimization to ensure that users have a great first impression and keep coming back.

🚅 Reduce loading times

Users expect web experiences to load more quickly than native experiences.

Native applications are downloaded ahead of launch, making it much easier to achieve fast loading times. Web applications must achieve better launch times while downloading assets after launch.

Keep assets small - users have to download assets over their network on each page load. Keeping assets small makes your experience accessible to users with slower internet speeds and speeds up the loading time. The average user has an internet speed of 50 megabits per second (mbps) and each extra second of waiting time increases bounce rates by 14%.
Load in assets as you go - one benefit of the browser is that assets can be continuously fetched over the network. Rather than loading everything in at once, only download it when you need it.
Show the user something as soon as you can - users will be visiting your game from a web page, which typically load very quickly. To keep the experience seamless, make sure to render a loading bar while resources are downloading.
Cache assets for future sessions - modern browsers expose features like IndexedDB and Service Workers that allow developers to store files on a user's device. This enables developers to cache assets on the first launch and load almost instantly on subsequent launches.
Reuse assets where possible - assets can also be cached in memory and reused while the application is running. We can then clone and modify cached meshes at any time, removing the need to redownload a similar mesh. For instance, we may load a single monster mesh that we color and resize instead of downloading multiple meshes with different colors and sizes.

🖥️ 💻 Prepare for cross-platform use 📱🥽

The same build runs across mobile, desktop, and XR platforms

Unlike native applications, where a separate build must be created for each platform, only one build is generated for the web. This simplifies deployment, but it makes it harder to ensure that apps perform well on all platforms. Developers should update performance settings while the app is running to ensure the best experience.

Set performance settings on launch - web users expect that the default graphics settings will perform well on launch. Use lower graphics settings on mobile and XR than on desktop.
Scale performance as you go - track performance metrics while the app is running, and scale graphics settings up or down accordingly.
Determine the correct input method - make sure that the correct input format is selected for each platform you support: touch inputs for mobile; keyboard/mouse on desktop; and controllers on XR. Be prepared to detect gamepads and alternate input sources on each platform.
Scale resolution according to the device - users expect UI elements and resolution to scale with the size of the screen. Mobile devices typically run at a lower resolution with larger UI elements, while desktops run at a higher resolution with proportionally smaller UI elements. Mobile devices also support both landscape and portrait mode; ensure that the experience renders well in portrait mode or notify the user that the game must run in landscape mode.

📻 Optimize scenes for the browser

Developers must tailor their experience towards running in a WebGL context

Running applications in the browser adds some overhead for extra security. Developers should take this extra overhead into account when designing their scene.

Account for WebGL execution overhead - the browser adds security measures to ensure that APIs like WebGL can't be used to run malicious code. This adds some CPU overhead to 3D web applications compared to native applications, reducing the total number of WebGL commands we can execute in a frame. However, once the CPU passes the command to the GPU, rendering performance is largely the same compared to an OpenGL application.
Understand how draw calls impact performance, and how to reduce them - CPU performance scales with the number of draw calls that occur in each frame. A draw call is a command that the engine sends to the GPU telling it to a draw a series of triangles or pixels. This operation happens quickly on the GPU, but is slow on the CPU, making it advantageous to batch draw calls.
Reduce scene complexity - You may need to reduce mesh counts, reduce polygon counts, reduce overdraw, remove expensive shaders (e.g. water, fire), remove particle effects, remove full-screen post-processing shaders, and/or remove transparency and reflections.

🚒 Select the best engine for the experience

Different web engines are well-suited for different types of experiences

There are numerous feature-packed 3D rendering engines for the web, like PlayCanvas, Unity, Three.js, and Babylon.js. Each engine has different strengths and weaknesses, explored more in Overview of 3D Web Rendering Engines.

Double-check the supported features - Built-in engine features generally perform better than home-brewed solutions, since they can be tested and iterated on by a large developer base. If you need features like rigid-body physics or photorealistic lighting, it could be better to develop in an engine that supports them by default, like Unity.
Be careful with file size - Without optimization, fully-featured C++ engines like Unity can have much larger application sizes than JavaScript engines like Babylon.js, Three.js, and PlayCanvas. If you don't need all of the features of Unity, using a javascript-based engine may make bundle size optimization easier. Users on mobile devices typically prefer smaller app sizes, as they may be on a cellular network.
Device support - If you plan to support mobile devices, some engines, like Unity and PlayCanvas, support touch controls out of the box. For more minimal engines like Three.js, you will need to use a third-party solution or implement touch controls yourself. If you plan to support XR, make sure your chosen engine has WebXR support.
Developer experience matters - Developers should use an engine that suits their strengths. If you're already comfortable with Unity, then continue with that engine. If you're looking to jump into JavaScript development, but still want an editor, PlayCanvas might be the right choice. For programming specialists, Three.js and Babylon.js provide more flexibility.