PROPOSED Web Performance Working Group Charter

The mission of the Web Performance Working Group is to provide methods to observe and improve aspects of application performance of user agent features and APIs.

Join the Web Performance Working Group.

Charter Status	See the group status page and detailed change history.
Start date	01 December 2023
End date	01 December 2025
Chairs	Nic Jansma, Akamai Yoav Weiss, Google
Team Contacts	Carine Bournez (0.2 FTE)
Meeting Schedule	Teleconferences: bi-weekly Face-to-face: we will meet during the W3C's annual Technical Plenary week; one additional face-to-face meeting per year may be scheduled by consent of the participants. IRC channel: #webperf

Motivation and Background

Web developers are building sophisticated applications where application performance is a critical feature. Web developers want the ability to observe the performance characteristics of their applications, and they want the ability to write more efficient applications, using well-defined interoperable methods. Their methods must be both secure and privacy-enabling by design, using well-defined interoperable methods that conform to the current Web browser security model.

Scope

The Web Performance Working Group's scope of work includes user agent features and APIs to observe and improve various aspects of application performance:

Measurement
The WG will deliver APIs to measure network and rendering performance, responsiveness and interactivity, memory and CPU use, application failures, and other aspects of the user’s experience, from the perspectives of both application loading and continuous user interaction. In particular, the group will deliver means to measure user experience metrics in popular web architectures, such as single-page apps, as well as means to collect those measurements.
Scheduling
The WG will deliver APIs to enable developers to improve scheduling of application work as well as use of network resources, to minimize loading times and ensure ideal user experience.
Adaptation
The WG will deliver APIs to enable developers to deliver resources adapted to the user’s device, preferences, conditions, or other circumstances.

Such deliverables will apply to desktop and mobile browsers and other non-browser environments where appropriate, and will be consistent with Web technologies designed in other working groups including HTML, CSS, Web Application Security, Web Apps, Device and Sensors, and SVG. The Group will strive for its deliverables to be well-integrated with other specifications where appropriate.

In addition to developing Recommendation Track documents, the Web Performance Working Group may provide specification review to other Groups, and will collaborate with relevant incubations. Such collaboration can be around web platform specifications, but can also include relevant developer or industry conventions, potentially applied in non-browser environments, as long as it's aligned with the Working Group's scope and mission.

Out of Scope

The following features are out of scope, and will not be addressed by this working group.

performance data analysis techniques or algorithms.

Deliverables

Updated document status is available on the group publication status page.

Draft state indicates the state of the deliverable at the time of the charter approval.

The Working Group intends to publish the latest state of their work as Candidate Recommendations, upgrading specifications with Candidate Recommendation Snapshots. Alternatively, ongoing work may be published as Recommendations to be updated further with Candidate Changes.

The Working Group expects to gradually move all of its deliverables to this model. Beyond that, the WG expects to converge at least some of its deliverables into a smaller number of specifications.

Normative Specifications

The Web Performance Working Group will deliver the following W3C normative specifications:

High Resolution Time

This document defines an API that provides the current time in sub-millisecond resolution such that it is not subject to system clock skew or adjustments.

Draft state: Working Draft

Next Recommendation expected completion: Maintained in CR

Latest publication: 25 April 2023
Patent Review Draft (level 3): https://www.w3.org/TR/2020/WD-hr-time-3-20201001/
Reference Draft (level 2): https://www.w3.org/TR/2018/CR-hr-time-2-20180301/
associated Call for Exclusion on 01 March 2018 ended on 30 April 2018
Produced under Working Group Charter: https://www.w3.org/2016/07/webperf.
Planned work: The specification defines time-related concepts beyond just high-resolution timers. It should be renamed to reflect that.

Performance Timeline

This specification defines a unified interface to store and retrieve performance metric data.

Draft state: Candidate Recommendation Draft

Next Recommendation expected completion: Maintained in CR

Latest publication: 15 November 2022
Reference Draft: https://www.w3.org/TR/2021/CR-performance-timeline-20211202/
associated Call for Exclusion on 02 December 2021 ended on 31 January 2022
Produced under Working Group Charter: https://www.w3.org/2021/02/webperf.html.

Resource Timing

This specification defines an interface for web applications to access the complete timing information for resources in a document or in a worker.

Draft state: Candidate Recommendation Draft

Next Recommendation expected completion:Maintained in CR

Latest publication: 11 May 2023
Reference Draft: https://www.w3.org/TR/2022/CR-resource-timing-20221004/
associated Call for Exclusion on 04 October 2022 ended on 03 December 2022
Produced under Working Group Charter: https://www.w3.org/2021/02/webperf.html.

This specification defines an interface for web applications to access the complete timing information for navigation of a document.

Draft state: Working Draft

Next Recommendation expected completion: maintained in CR

Note: after Level 2 of Navigation Timing is ratified, future development of new Navigation Timing features will be done within Resource Timing; Navigation Timing will be merged with Resource Timing.

Latest publication: 07 June 2023
Reference Draft: https://www.w3.org/TR/2015/WD-navigation-timing-2-20150120/
associated Call for Exclusion on 31 January 2013 ended on 30 June 2013
Produced under Working Group Charter: https://www.w3.org/2013/01/webperf.
Planned work: The specification should be folded into the Resource Timing specification, on which it relies.

User Timing

An interoperable means for site developers to capture timing information with a developer supplied name. The user agent captures the time stamp at the point and time specified in the code executing in the user agent.

Draft state: Candidate Recommendation Draft

Next Recommendation expected completion: Maintained in CR

Latest publication: 26 April 2023
Reference Draft: https://www.w3.org/TR/2021/CR-user-timing-20211202/
associated Call for Exclusion on 02 December 2021 ended on 31 January 2022
Produced under Working Group Charter: https://www.w3.org/2021/02/webperf.html

Beacon

An interoperable API for site developers to asynchronously transfer data from the user agent to a web server, with a guarantee from the user agent that the data will be eventually sent.

Draft state: Candidate Recommendation Draft

Next Recommendation expected completion: Maintained in CR

Latest publication: 03 August 2022
Reference Draft: https://www.w3.org/TR/2017/CR-beacon-20170413/
associated Call for Exclusion on 13 April 2017 ended on 12 June 2017
Produced under Working Group Charter: https://www.w3.org/2016/07/webperf.

Cooperative Scheduling of Background Tasks

An API that web page authors can use to cooperatively schedule background tasks such that they do not introduce delays to other high priority tasks that share the same event loop, such as input processing, animations and frame compositing.

Draft state: Working Draft

Next Recommendation expected completion: Expected to move to CR in 2024

Latest publication: 28 June 2022
Reference Draft: https://www.w3.org/TR/2017/CR-requestidlecallback-20170131/
associated Call for Exclusion on 02 February 2017 ended on 01 April 2017
Produced under Working Group Charter: https://www.w3.org/2016/07/webperf.
Planned work: The specification should be unified with other Scheduling APIs, once they mature.

Long Tasks API

This specification defines an API that web page authors can use to detect presence of "long tasks" that monopolize the UI thread for extended periods of time and block other critical tasks from being executed - e.g. reacting to user input.

Draft state: Working Draft

Next Recommendation expected completion: Expected CR

Latest publication: 07 September 2017
Reference Draft: https://www.w3.org/TR/2017/WD-longtasks-1-20170907/
associated Call for Exclusion on 07 December 2017 ended on 04 February 2018
Produced under Working Group Charter: https://www.w3.org/2016/07/webperf.
Planned work: Expanding the API to include long animation frames.

Paint Timing

An interoperable API for site developers to capture the set of key moments during pageload - e.g. first paint and first contentful paint.

Draft state: Working Draft

Next Recommendation expected completion: Expected CR in 2024

Latest publication: 03 July 2023
Reference Draft: https://www.w3.org/TR/2017/WD-paint-timing-20170907/
associated Call for Exclusion on 07 December 2017 ended on 04 February 2018
Produced under Working Group Charter: https://www.w3.org/2016/07/webperf

Server Timing

This specification enables a server to communicate performance metrics about the request-response cycle to the user agent. It also standardizes a JavaScript interface to enable applications to collect, process, and act on these metrics to optimize application delivery.

Draft state: Working Draft

Next Recommendation expected completion: Expected CR in 2024

Latest publication: 11 April 2023
Reference Draft: https://www.w3.org/TR/2017/WD-server-timing-20170713/
associated Call for Exclusion on 13 July 2017 ended on 10 December 2017
Produced under Working Group Charter: https://www.w3.org/2016/07/webperf

Device Memory

This specification defines a JavaScript API and HTTP Client Hint header to surface device capability for memory — i.e. device RAM, in order to enable web apps to customize content depending on device memory constraints.

Draft state: Working Draft

Next Recommendation expected completion: Expected CR in 2024

Latest publication: 22 July 2022
Reference Draft: https://www.w3.org/TR/2018/WD-device-memory-1-20180925/
associated Call for Exclusion on 25-Sep-2018 ended on 22-Feb-2019
Produced under Working Group Charter: https://www.w3.org/2018/09/webperf/

Reporting API

This specification defines a generic reporting framework which allows web developers to associate a set of named reporting endpoints with an origin. Various platform features (like Content Security Policy, Network Error Reporting, and others) will use these endpoints to deliver feature-specific reports in a consistent manner.

Draft state: Working Draft

Next Recommendation expected completion: Expected CR

Latest publication: 12 May 2023
Reference Draft: https://www.w3.org/TR/2016/WD-reporting-1-20160407/
associated Call for Exclusion on 7 April 2016 ended on 4 September 2016
Produced under Working Group Charter: https://www.w3.org/2015/06/webperf.

Network Error Logging

This specification defines a mechanism that enables developers to declare a network error reporting policy for a web application. A user agent can use this policy to report encountered network errors that prevented it from successfully fetching requested resource.

Draft state: Working Draft

Next Recommendation expected completion: Expected CR

Latest publication: 25-Sep-2018
Reference Draft: https://www.w3.org/TR/2014/WD-navigation-error-logging-20140211/
associated Call for Exclusion on 12-Feb-2014 ended on 12-Jul-2014
Produced under Working Group Charter: https://www.w3.org/2013/01/webperf

Event Timing

This specification defines an API that provides web page authors with insights into the latency of certain events triggered by user interactions.

Draft state: Working Draft

Next Recommendation expected completion:Expected to move to CR in 2024

Latest publication: 03 July 2022
Reference Draft: https://www.w3.org/TR/2022/WD-event-timing-20220524/
associated Call for Exclusion on 24 May 2022 ended on 21 October 2022
Produced under Working Group Charter: https://www.w3.org/2021/02/webperf

Largest Contentful Paint

This specification defines an API that enables monitoring the largest paint an element triggered on screen.

Draft state: First Public Working Draft

Next Recommendation expected completion:

Latest publication: 24 May 2022
Reference Draft: https://www.w3.org/TR/2022/WD-largest-contentful-paint-20220524/
associated Call for Exclusion on 24 May 2022 ended on 21 October 2022
Produced under Working Group Charter: https://www.w3.org/2021/02/webperf

Other Deliverables

The Group maintains two non-normative documents:

A Primer for Web Performance Timing APIs document to facilitate the understanding of the interrelationships between its deliverables.
Planned work: Updating it to include new specs, remove deprecated ones and more.
A Performance APIs, Security and Privacy document
Planned work: Reviewing and updating the content, and adding a section on the principals and value of performance measurements.

Other non-normative documents may be created such as:

Security and Privacy considerations for Performance APIs
Test suites for each specification;
Use cases documents to support development and exploration of performance-critical web platform features and APIs;
Primer or Best Practice documents to support web developers when designing applications with performance in mind;
Developer and user guides for its normative specifications;
Best practice document explaining how data is commonly gathered between the client and the server.

The WG will also explore the possibility of renewing work on the HAR file format.

Timeline

Next meeting: TPAC 2024 in hybrid mode.

Success Criteria

There should be testing plans for each specification, starting from the earliest drafts.

To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests. Testing efforts can be conducted via the Web Platform Tests project.

Each specification should contain sections detailing all known security and privacy implications for implementers, Web authors, and end users.

This Working Group expects to follow the TAG Web Platform Design Principles.

All new features should be supported by at least two intents to implement before being incorporated in the specification.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

W3C Groups

Web Applications Working Group: This Working Group develops APIs for client-side development and for markup vocabularies for describing and controlling client-side application behavior.
Web Application Security Working Group: This Working Group develops security and policy mechanisms to improve the security of Web Applications, and enable secure cross-site communication.
CSS Working Group: The group develops and maintains CSS, which is relevant for specifications such as page visibility.
Privacy Interest Group: This group monitors ongoing privacy issues that affect the Web, investigates potential areas for new privacy work, and provides guidelines and advice for addressing privacy in standards development.
Web Platform Incubator Community Group: This group provides a lightweight venue for proposing, incubating and discussing new web platform features. The Web Performance Working group will incubate and review new proposals that are within scope of our charter within the WICG. Once such WICG-incubated proposal is implemented and available in at least one major browser, and has support from one more, it may be adopted by the Web Performance Working group.

External Organizations

ECMA Technical Committee 39 (TC39): This is the group responsible for ECMAScript standardization, and related ECMAScript features like E4X. As the Web Performance Working Group will be developing ECMAScript APIs, it should collaborate with TC39.
Internet Engineering Task Force: The IETF is responsible for defining robust and secure protocols for Internet functionality, in particular HTTP. The Working Group should coordinate protocol-related work (e.g. profiles of hybi or HTTP) with the appropriate IETF WGs.
Web Hypertext Application Technology Working Group (WHATWG): The Web Hypertext Application Technology Working Group (WHATWG) is a community of people interested in evolving the web through standards and tests.

Participation

To be successful, this Working Group is expected to have 9 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.

Communication

Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Web Performance Working Group home page.

Most Web Performance Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

This group primarily conducts its technical work on GitHub in the relevant specifications repositories. The public is invited to review, discuss and contribute to this work.

The group may use a Member-confidential mailing list for administrative purposes.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the licensing information.

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):

Charter Period	Start Date	End Date	Changes
Initial Charter	2010-08-18	2011-06-30	none
Rechartered	2011-04-25	2012-06-30	Added Page Visibility, Efficient Script Yielding, Display Paint notifications
Rechartered	2013-06-06	2015-05-31	Added Performance Timeline, Timing control for script-based animations, Resource Priorities, Beacon, Diagnostics, Pre-render, Display Performance, Async scroll, HAR. Removed Display Paint notifications.
Rechartered	2015-06-25	2016-05-31	Added Server Timing, Resource Hints, NEL, Preload (previously Pre-render), Frame Timing, CPU and Memory monitoring. Removed Resource Priorities, Diagnostics, Display Performance, Async scroll.
Rechartered	2016-06-01	2018-05-31	Removed CPU and Memory monitoring. Moved to WICG: Frame Timing, Server Timing, NEL, Reporting. Moved to Software and Document license.
Rechartered	2018-09-20	2020-06-30	Removed Memory Pressure. Added: Reporting, NEL, Device Memory.
Extended	2020-07-01	2020-12-31	N/A
Extended	2021-01-01	2021-02-10	N/A
Rechartered	2021-02-11	2023-02-28	Resource Hints and Preload will be moved under WhatWG's responsibility. WG switch to the Patent Policy 2020.
Extended	2023-03-01	2023-08-31	N/A
Extended	2023-09-01	2023-11-30	N/A
Rechartered	2023-12-01	2025-12-01	N/A

Change log

Changes to this document are documented in this section.