Optimization Recommendations and Requirements

Learn about fundamental optimization metrics and the optimization requirements in VIVERSE.

---

Quantifying the Characteristics of Good Optimization

In Introduction to Optimizing for the Web, we discussed the qualitative characteristics of a well-optimized experience: fast-loading, fluid, stable, responsive, legible, and scalable. In this section, we present quantifiable application metrics and scene metrics, and show how these metrics correlate to a well-optimized scene.

Application metrics are the benchmarks against which we measure optimization, and they are generated by browser and engine profiling tools. Scene metrics are the levers that developers use to improve the application metrics. These scene metrics correspond to quantifiable properties from the rendering pipeline described above. Application metrics tell us what to optimize, scene metrics tell us how to optimize. All of these metrics are moderated by device characteristics and other external factors, which affect the scalability and potential reach of your application.

Application Metrics to Optimize

Metric	Description	Target Values
Time to initial display (TTID)	The amount of time (in seconds) that it takes to display the first frame of an application from a cold start. In 3D applications, it is important to show a loading bar as soon as possible. This lets the user know that the app is in a loading state and not frozen.	✅: < 1.5 s 🟡: 1.5 - 4 s ❌: > 4 s
Time to full display (TTFD)	The amount of time (in seconds) that it takes for the app to become interactive. For example, this would be the amount of time it takes for the user to gain control of the camera or for clickable UI elements to load. In 3D web applications, it is best to minimize TTFD, as it increases user retention.	✅: < 10 s 🟡: 10 - 30 s ❌: > 30 s
Interaction to next paint (INP)	Measures the amount of time (in milliseconds) between a user interaction and the next frame. This tracks the direct scripting overhead of user interactions. This metric is most relevant to interactions that incur asset loading, shader compilation, or extensive data processing, like entering a new area of the world, as these interactions can cause the app to momentarily freeze.	✅: < 16 ms 🟡: 16 - 75 ms ❌: > 75 ms
Frame rate, or frames per second (FPS)	The frequency at which frames are rendered to the screen. Applications with higher FPS appear more fluid, while applications with low FPS can look like a slideshow, making it difficult for the user to control their character.	Mobile & Desktop ✅: > 60 fps 🟡: 45 - 60 fps ❌: < 45 fps XR: ✅: > 72 fps 🟡: 60 - 72 fps ❌: < 60 fps
5th percentile minimum frame rate (5th %ile FPS)	High variance in frame time can result in a poor user experience, as this can be perceived as "choppiness" and break immersion. To get a sense of how much choppiness there is an application, we can take the 5th percentile value from n samples of the frame rate. In a stable application, this value will be around 80% of the median FPS.	Mobile & Desktop ✅: > 45 fps 🟡: 30 - 45 fps ❌: < 30 fps XR: ✅: > 60 fps 🟡: 45 - 60 fps ❌: < 45 fps
Image Quality	Indicates how well the real-time rendered scene matches an idealized version of the scene. A heuristic for this metric is the amount of resolution downscaling that is applied to the canvas relative to the screen. This is described more below.	✅: 100% scaling 🟡: 85 - 100% scaling ❌: < 85% scaling
Memory Usage	Higher memory usage (in megabytes/MB) generally correlates to poorer performance on lower-end devices, which typically have less available system memory (RAM) and smaller CPU caches. Higher memory usage also correlates to higher garbage collection overhead, which can cause the scene to momentarily freeze. If too much memory is used, the browser tab will crash.	✅: < 800 MB 🟡: 800 - 1600 MB ❌: > 1600 MB

Scene Metrics to Optimize

Metric	Description
Asset sizes	By decreasing the file size of static assets (models, textures, code), users can improve the loading time of the application (TTID, TTFD) and time spent loading new areas. Asset sizes can be improved by decimating meshes, reducing texture size, and minifying code.
Framebuffer resolution and scale	There are 3 types of resolution that impact image quality: framebuffer resolution, window resolution, and device resolution. The framebuffer resolution of an application is the number of pixels that are output into the framebuffer, represented as a (width, height) pair. This is distinct from the window resolution, which is the number of CSS pixels displayed to the user. Framebuffer scale represents the ratio of framebuffer resolution divided by window resolution, where higher values represent a more legible image. Lowering framebuffer scale can increase FPS at the expense of image quality. Device resolution is the number of physical pixels in the screen of the device. On devices with high pixel density, multiple physical pixels will make up a single CSS pixel, resulting in a higher quality image. The ratio of phyiscal pixels to CSS pixels is measured by the devicePixelRatio API.
Texture resolution	The resolution of a texture dictates how legible corresponding models, text, and shader effects are in the application. Reducing texture resolution can increase FPS by decreasing image quality. This is distinct from the downloaded texture size, as high-resolution textures can be downsampled at runtime, providing an option for runtime scalability.
Draw call count	In 3D applications, draw calls tend to be the primary bottleneck. Draw calls are very CPU intensive, so FPS inversely scales with the number of draw calls in the scene. To reduce draw calls, developers can reuse materials across meshes, merge static meshes, and use instancing to clone meshes.
Scripting overhead	The amount of time spent each frame running application logic (in milliseconds). In a 3D experience, some time is spent each frame transforming meshes, responding to user inputs, and updating animations. Developers must optimize this per-frame scripting time to be as small as possible to ensure higher FPS. Intermittent scripting times increases are also a primary contributor to low 5th percentile minimums, as lots of application logic may need to be run when entering a new area or processing a large amount of incoming data.
Shader overhead	Time spent in shaders is difficult to measure directly, but it can be inferred from the total amount of time spent on the GPU. To reduce shader time, developers can remove expensive functions (pow, log, sin), use built-in functions, use lower precision variables, and avoid repeated calculations.

External Factors Affecting Scalability

Application metrics are affected by factors outside of a developer's control. In particular, a developer cannot control the hardware specifications (CPU + GPU + RAM) or internet connection that the experience will run on, making it difficult to optimize the experience for all users. Developers should aim to provide a good experience on the median hardware specs for each platform (mobile, desktop, XR) that their experience supports and adjust asset sizes according to median network bandwidth. A good approximation for this is to target a flagship device that is a few years old (an iPhone 12 or Galaxy s20 in 2025), and to expect around 50 mbps network bandwidth.

Device Class

3D capable devices are typically split into 3 categories: Mobile (Android and iOS tablets and phones), Desktop (laptop and desktop computers), and recently XR (augmented and virtual reality headsets). Desktops are the most powerful, and can render experiences at higher fidelity than mobile devices and XR headsets. If you plan to support multiple platforms, expect to optimize code and assets for each platform.

CPU

A CPU's speed is determined by three main factors: clock speed, core count, and cache size. Clock speed determines how fast an individual function can complete on a CPU, higher clock speeds corresponding to faster execution. Higher cache sizes allow the CPU to access data very quickly, avoiding relatively expensive RAM operations. However, leveraging cache size often relies on careful optimization. Core count determines how much parallelism an application can leverage. A program can theoretically cut scripting time proportionally to the number of cores, but this requires additional optimization with Web Workers or WebAssembly. Increasing CPU speed allows for more complex scripting and higher draw call counts. Loading times also tend to increase, as assets are processed more quickly once they are downloaded.

GPU

A GPU's speed is determined by memory size (VRAM), GPU clock speed, and core count. For GPUs, core count and memory size are more important than clock speed, as GPUs have to perform many operations in parallel. Having more cores and more memory allow GPUs to process larger textures and more vertices with higher precision. Increased clock speeds typically decrease the amount of time spent in shaders, though this is typically only a bottleneck with very expensive shaders.

RAM

The amount of system memory, or RAM, that a user's device has will limit the types of experience that they are able to run. RAM is used to keep active program data readily available, so more complex experiences will require more RAM. Typical mobile devices will have 1GB - 8GB of RAM, which is enough to run smaller experiences with good performance. Desktop and laptop computers typically have 8GB - 32GB of RAM, which is enough to run medium experiences. The highest-quality experiences require 16+ GB of available RAM.

Network

A user's network speed is out of a developer's control. If a user does has less than 1 MB/s internet speed, they will have trouble accessing 3D experiences in a reasonable time. Nevertheless, developers should tune asset sizes such that users with a wide range of internet speeds can access their experience. Developers can also take use of progressive loading to download assets throughout the experience runtime.

Correlating Qualitative Characteristics to Metrics

Characteristic	Application Metrics	Scene Metrics	External Factors
Fast Loading	TTID TTFD INP	Asset Sizes	Network Speed CPU Clock Speed
Fluid	FPS	Draw Call Count Framebuffer Resolution Scripting Overhead Shader Overhead Texture Resolution	CPU Clock Speed GPU VRAM GPU Clock Speed
Stable	5th Percentile Frame Rate Memory Usage	95th percentile shader overhead 95th percentile scripting overhead 95th percentile draw call count	RAM CPU Clock Speed GPU VRAM GPU Clock Speed
Responsive	Interaction to Next Paint (INP)	Maximum scripting overhead Maximum shader overhead Maximum draw call count	CPU Clock Speed
Legible	Image Quality	Texture resolution Framebuffer scaling	Screen Resolution Screen Size
Scalable	For scalability, validate all application metrics on each device class you plan to support (mobile, XR, desktop)	Texture resolution may need to be tuned for each device Draw call count may need to be tuned for each device	Device Classes Supported

---

Optimization Requirements for VIVERSE

Coming soon...