Well-deployed technologies
The Web Performance Working Group developed a number of specifications that expose timing hooks to Web applications, to analyze time spent doing various tasks.
The High-Resolution Time exposes a monotonic sub-millisecond resolution clock to Web applications so that they can precisely measure time elapsed between two events. The Performance Timeline defines a unified interface to store and retrieve performance metric data. Individual performance metric interfaces are defined in separate specifications:
- Navigation Timing exposes timing information related to navigation and elements;
- Resource Timing exposes timing information for resources in a document;
- User Timing help applications measure the performance of their applications using high precision timestamps.
The API to determine whether a Web page is being displayed (Page Visibility API) can also be used to adapt the usage of resources to the need of the Web application, for instance by reducing network activity when the page is minimized.
The Timing control for script-based animations API can help reduce the usage of resources needed for playing animations.
Beyond optimization of resources, the perceived reactivity of an application is also a critical aspect of the mobile user experience. The thread-like mechanism made possible via Web Workers allows keeping the user interface responsive by offloading the most resource-intensive operations into a background process.
The Mobile Web Application Best Practices provide general advice on how to build Web applications that work well on mobile devices, taking into account in particular the needs for optimization.
| Feature | Specification | Maturity | Current implementations |
|---|---|---|---|
| Timing Hooks | High Resolution Time |  | Shipped |
| Performance Timeline | | N/A | |
| Navigation Timing | | Shipped | |
| Resource Timing Level 1 |  | Shipped | |
| User Timing | | Shipped | |
| Page Visibility Detection | Page Visibility | | Shipped |
| Animation Optimization | requestAnimationFrame in HTML 5.1 | | Shipped |
| Threading | Web workers in HTML (Living Standard) |  | Shipped |
| Optimization Best Practices | Mobile Web Application Best Practices | | N/A |
Technologies in progress
The Resource Hints and Preload specifications let developers optimize the download of resources by enabling to delay either the download or the execution of the downloaded resource.
The Cooperative Scheduling of Background Tasks specification defines the requestIdleCallback method that allows scheduling an operation at the next opportunity when the app is not processing another operation.
The Service Workers specification defines a mechanism that allows applications to intercept outgoing network requests and respond to them directly. Applications can take advantage of this mechanism to implement a flexible cache logic directly and thus avoid lengthy requests to the server.
The Battery status API allows adjusting the use of resources to the current level of power available in the battery of a mobile device. However, note the future of this last specification is uncertain due to identified potential privacy-invasive usage of the API.
Server Timing enables a server to communicate performance metrics about the request-response cycle to the user agent, and allows applications to act on these metrics to optimize application delivery.
The Long Tasks API exposes a mechanism to detect long running tasks that monopolize the user interface's main thread for extended periods of time.
The Paint Timing specification allows the application to capture a series of key moments such as first paint and first contentful paint during page load.
WebAssembly is a low-level bytecode format that runs with near-native speed in web browsers and supports compilation from C, C++, and other languages. It also defines an execution environment that attempts to maximize performance and interoperate gracefully with JavaScript and the Web, while ensuring security and consistent behavior across a variety of implementations.
The use of infinite scrolling lists, where more and more content is loaded and rendered as the user scrolls, is very common on mobile devices. Such lists provide a better user experience than pagination on touch screens. Applications unfortunately need to continuously poll layout information of DOM elements synchronously to implement this pattern, which is a source of significant performance overhead. The Intersection Observer specification defines an API to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document's viewport, providing an efficient mechanism to retrieve the information needed to implement infinite scrolling.
| Feature | Specification | Maturity | Current implementations |
|---|---|---|---|
| Network Prioritization | Resource Hints |  | Under consideration Experimental Shipped |
| Preload | | Experimental Shipped | |
| Priority Handling | Cooperative Scheduling of Background Tasks |  | Under consideration Shipped |
| Caching | Service Workers 1 | | Experimental In development Shipped |
| Battery Status | Battery Status API | | Shipped |
| Timing Hooks | Server Timing | | N/A |
| Long Tasks API 1 | | N/A | |
| Paint Timing 1 | | Under consideration Shipped | |
| Low-level Bytecode Format | WebAssembly |  | Experimental Shipped |
| Infinite scrolling | Intersection Observer | |
Exploratory work
The work on the Frame Timing API aims at providing detailed information on the frame-per-second obtained when an application is running on the user device.
| Feature | Specification | Group | Implementation intents |
|---|---|---|---|
| Rendering Performance | Frame Timing | Web Performance Working Group | N/A |
Features not covered by on-going work
- More fine-grained network prioritization
- Existing mechanisms to specify priorities for resource fetching, such as the
preloadlink type, are quite coarse. Applications could benefit from a declarative mechanism to specify the relative priorities of resources that the user agent will eventually need to fetch. Current discussions in the Web Platform Incubator Community Group could lead to exploratory work in this space.