Copyright © 2016 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
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.
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 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.
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.
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.
<!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.
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]
PerformanceFrameTiming interfaceinterface PerformanceFrameTiming : PerformanceEntry {
};
nameentryTypeframe".startTimedurationThe PerformanceFrameTiming interface participates in the [Performance-Timeline-2] and extends the browser processing model.
TODO: define proper hook in the HTML spec...
Run the following steps prior to running step 1 of the browser processing model [HTML5]:
Performance object's now() method.Run the following steps after running step 8.10 of the browser processing model:
Performance object's now() method.PerformanceFrameTiming object.
startTime to
frame startTime.
duration to
frame duration.
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.
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.
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.
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.