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 enumerated in the Timing Entry Names Registry and defined in separate specifications:
Page Visibility Detection
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 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.
Low-level Bytecode Format
The CSS contain property can indicate that the element’s subtree is independent of the rest of the page. This also enables heavy optimizations by user agents when used well, in particular to skip over content that is off-screen knowing that it won't affect the rendering of the content that is on-screen.
The Timing control for script-based animations API can help reduce the usage of resources needed for playing animations.
Smooth scrolling performance is essential for a good user experience on the web, especially on touch-based devices. Through the
passive event listener option, developers can declare up-front that an event listener will not call
preventDefault() on the event, allowing the browser not to wait for the event listener to have run before it performs the default action associated with the event. This is particularly recommended on touch and wheel events to guarantee smooth scrolling. Note: some browsers automatically set the
passive flag on
touchmove by default.
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 WebDriver specification defines a remote control interface that enables introspection and control of user agents, typically useful to automate testing across multiple browsers, including mobile browsers.
Optimization Best Practices
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.
Technologies in progress
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.
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.
To ensure optimal performance when animating parts of an app, developers can make use of the CSS
will-change property to let browsers compute the animation ahead of its occurrence.
The CSS Animation Worklet API provides a method to create scripted animations that control a set of animation effects. The API is designed to make it possible for user agents to run such animations in their own dedicated thread to provide a degree of performance isolation from main thread.
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.
User agents may implement default rules for scrolling such as scroll chaining and overscroll affordances that web applications may wish to disable to enhance pull-to-refresh and infinite scrolling interaction paradigms, which are common on mobile devices. This can be achieved through scripting, but negatively affects scrolling performances as the application needs to listen to touch events without setting the
passive flag to override the default behavior when needed. The CSS
overscroll-behavior property introduces control over the behavior of a scroll container when its scrollport reaches the boundary of its scroll box, allowing web applications to disable default rules for scrolling efficiently.
The Identifiers for WebRTC's Statistics API defines a set of Web IDL objects that allow access to the statistical information about a RTCPeerConnection, allowing web apps to monitor the performance of the underlying network and media pipeline.
The Frame Timing API aims at providing detailed information on the frame-per-second obtained when an application is running on the user device.
The Event Timing API exposes a mechanism to measure the latency of some events triggered by user interaction.
The Element Timing API enables monitoring when large or developer-specified image elements and text nodes are displayed on screen.
The Layout Instability API provides web page authors with insights into the stability of their pages based on movements of the elements on the page that detract from the user's experience.
The Priority Hints specification lets developers signal the priority of each resource they need to download, complementing existing browser loading primitives such as preload.
Web applications are dynamic in essence and need to manipulate the DOM significantly to present rich content. Problem is updates to the DOM can cause jank (noticeable delay in visual updates) because the rendering phase is updated synchronously with user interactions and
requestAnimationFrame scripts. The Display Locking proposal introduces a new concept whereby developers can lock a DOM element and its subtree, preventing visual updates while the DOM gets updated. The developer will then be able to unlock the element, asynchronously, triggering the visual updates of the modified subtree without causing the rest of the page to jank.
Similarly, an early proposal to add
requestPostAnimationFrame would give applications a hook into the earliest possible time after last frame has been rendered, and thus allow them to prepare for the next rendering update. The proposal could also be useful to run code at a time when the page layout is guaranteed to be clean, e.g. to avoid synchronous layouts when modifying a CSS property through code and then querying the size or position of the underlying element.
Applications that need to run long tasks (e.g. when pages are loaded) need to make a tradeoff between loading pages quickly (or reducing task execution duration) and responding to input quickly. The Early detection of input events specification proposes an
isInputPending method that long running scripts can call synchronously, without losing time yielding to other scripts and events processing, to detect whether there are pending input events that their execution might delay from firing.
Applications that need to run long tasks may also want to regain control after yielding to the event loop before any other same or lower priority tasks are allowed to run. The
scheduler.yield() function is being proposed to solve that issue.
Generally speaking, applications have little control over task priorities when they schedule them. The
scheduler.postTask() proposal would create a unified API to schedule prioritized work.
The creation of a built-in