| 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 |
| 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. |
| Characteristic | Application Metrics | Scene Metrics | External Factors |
|---|---|---|---|
| Fast Loading |
|
|
|
| Fluid |
|
|
|
| Stable |
|
|
|
| Responsive |
|
|
|
| Legible |
|
|
|
| Scalable |
|
|
|