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 document was moved to the Web Platform Incubator Community Group.

This document was published by the Web Performance Working Group as a Working Group Note. 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 Group Note 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.

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
Fig. 1 Illustration of a frame within an event loop

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. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, and SHOULD are to be interpreted as described in [RFC2119].

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps MAY be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [WebIDL]

3. Frame Timing

3.1 PerformanceFrameTiming interface

interface PerformanceFrameTiming : PerformanceEntry {
};

3.1.1 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 [HR-Time-2] indicating the frame start time.
duration
This attribute MUST return a DOMHighResTimeStamp indicating the difference between the startTime's of two successive frames.

3.2 Processing

The PerformanceFrameTiming interface participates in the [Performance-Timeline-2] 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 [HTML5]:

  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 8.10 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. For each fully active Document in docs, 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.

4. 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

[HR-Time-2]
Ilya Grigorik; James Simonsen; Jatinder Mann. W3C. High Resolution Time Level 2. 13 July 2016. W3C Working Draft. URL: https://www.w3.org/TR/hr-time-2/
[HTML5]
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. W3C. HTML5. 28 October 2014. W3C Recommendation. URL: https://www.w3.org/TR/html5/
[Performance-Timeline-2]
Ilya Grigorik. W3C. Performance Timeline Level 2. 21 April 2016. W3C Working Draft. URL: https://www.w3.org/TR/performance-timeline-2/
[RFC2119]
S. Bradner. IETF. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[WebIDL]
Cameron McCormack; Boris Zbarsky. W3C. WebIDL Level 1. 8 March 2016. W3C Candidate Recommendation. URL: https://www.w3.org/TR/WebIDL-1/