Abstract

This specification defines an interface for web applications to access runtime performance information of the browser event loop, enabling them to identify and fix issues that cause delayed rendering, processing of input, and other critical work necessary to deliver a smooth and responsive user experience.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a work in progress and may change without any notices.

This document was published by the Web Performance Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-web-perf@w3.org (subscribe, archives) with [Frame Timing] at the start of your email's subject. All comments are welcome.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

Table of Contents

1. Introduction

This section is non-normative.

In order to deliver an interactive user experience the browser processing model runs a continuous event loop at a certain update frequency - e.g. 60Hz refresh rate. Each execution of the event loop is responsible for processing scheduled tasks (e.g. input, touch, scroll, etc.), associated microtasks, scheduled callbacks (e.g. requestAnimationFrame, requestIdleCallback), running the necessary rendering updates, and other necessary work.

frame diagram

If all of the work within each execution of the event loop (i.e. within a "frame") is completed in allotted time budget (e.g. 16.6ms for 60Hz refresh rate), the browser can guarantee a smooth and responsive experience. However, if the work within the frame exceeds this time budget, for whatever reason, then one or more frames is skipped, resulting in inconsistent response, processing, and rendering times, which hurts the user experience.

Example 1
<!doctype html>
<html>
<head>
<script>
  // subscribe to Frame Timing notifications for slow frames
  var observer = new PerformanceObserver(function(list) {
    var perfEntries = list.getEntries();
    for (var i = 0; i < perfEntries.length; i++) {
      // Process slow-frame notifications:
      // - adapt processing and rendering logic
      // - aggregate and report back for analytics and monitoring
      // - ...
      console.log("Uh oh, slow frame: ", perfEntries[i]);
   });
  observer.observe({entryTypes: ['frame']});
</script>
</head>
<body>
...
</body>
</html>

The Frame Timing API enables web developers to monitor the performance of their applications, as experienced by their users, by observing when the browser is unable to deliver the desired refresh rate due to long-running frames that exceed the allotted time budget. By identifying such cases, and their cause, web developers can adapt or fix their logic to stay within the allotted budget and help the browser deliver an improved user experience.

2. Frame Timing

2.1 PerformanceFrameTiming interface

interface PerformanceFrameTimingEntry : PerformanceEntry {
    serializer = {inherit, attribute};
};

2.1.1 Serializer

Instances of this interface are serialized as a map with entries from the closest inherited interface and with entries for each of the serializable attributes.

2.1.2 Attributes

name
This attribute MUST return the current document's address.
entryType
This attribute MUST return the DOMString "frame".
startTime
This attribute MUST return a DOMHighResTimeStamp indicating the frame start time.
duration
This attribute MUST return a DOMHighResTimeStamp indicating the difference between the startTime's of two successive frames.

2.2 Processing

The PerformanceFrameTiming interface participates in the [Performance-Timeline] and extends the browser processing model.

Issue 1

TODO: define proper hook in the HTML spec...

Run the following steps prior to running step 1 of the browser processing model:

  1. Let frame startTime be the value that would be returned by the Performance object's now() method.

Run the following steps after running step 9 of the browser processing model:

  1. Let frame endTime be the value that would be returned by the Performance object's now() method.
  2. Let frame duration be the difference between the values of frame endTime and frame startTime.
  3. If frame duration value exceeds the user agent determined time budget for the frame, then:
    1. Let entry be a new PerformanceFrameTiming object.
    2. Set entry startTime to frame startTime.
    3. Set entry duration to frame duration.
    4. Queue entry.

This specification does not mandate any particular value for time budget for the frame that results in delivery of a PerformanceFrameTiming entry. This value is subject to user agent configuration and runtime factors. For example, the user agent may set different target update frequencies (60Hz, 30Hz, etc) and adjust this target at runtime based on device performance, power consumption, responsiveness, and other requirements.

The user agent SHOULD adjust its duration thresholds to match the expected frame duration and update frequency to avoid reporting false-positives to the developer. For example, if the user agent is idle, it may interleave long idle callbacks (e.g. 50ms idle callback via requestIdleCallback) and the duration threshold for slow frames should be adjusted accordingly to account for such frames.

Issue 2

Explain why frame is slow (in v2, probably): current definition reports slow frames, but there is no simple mechanism to determine what was the culprit (e.g. slow input handler vs. rAF vs. expensive paint). We may want to extend the PerformanceFrameTiming interface with additional attributes that capture this.

3. Privacy and Security

This section is non-normative.

The PerformanceFrameTiming interface exposes timing information about the processing costs of the browser event loop. To limit the exposed information the interface is restricted to reporting slow frames only, which are already observable through other means (e.g. requestAnimationFrame), and the user agent is allowed to set and exercise own thresholds for delivery of slow frame events.

A. Acknowledgments

Thanks to Enne Walker, Rick Byers, Chris Harrelson, Timothy Robert Ansell, Vladimir Levin, and Nat Duca for their helpful comments and contributions to this work.

B. References

B.1 Normative references

[Performance-Timeline]
Jatinder Mann; Zhiheng Wang. Performance Timeline. 12 December 2013. W3C Recommendation. URL: http://www.w3.org/TR/performance-timeline/