[DRAFT] 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.

This draft charter is available on GitHub. Feel free to raise issues.

Charter Status See the group status page and detailed change history.
Start date 1 June 2026
End date 1 June 2028
Chairs Nic Jansma, Akamai
Yoav Weiss, Shopify
Team Contacts Carine Bournez (0.15 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:

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:

Long Animation Frames

This document defines an API that web page authors can use to detect presence of "long animation frames" 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:editors draft

Expected completion: @@TBD

Performance Timeline

This specification defines an interface for web applications to access timing information related to navigation and elements. It is used by other specifications, like User Timing.

Draft state: CRD

Expected completion: Maintained in CR

Latest publication: 2025-05-21

Exclusion Draft: https://www.w3.org/TR/2012/WD-performance-timeline-20120508/
Exclusion period began on 2012-05-08 and ended on 2012-07-07.

Exclusion Draft Charter: Produced under Working Group Charter: http://www.w3.org/2011/04/webperf

Beacon

This specification defines an interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with the user agent taking the responsibility to eventually send the data.

Draft state: CRD

Expected completion: @@TBD

Latest publication: 2022-08-03

Exclusion Draft: https://www.w3.org/TR/2017/CR-beacon-20170413/
Exclusion period began on 2017-04-13 and ended on 2017-06-12.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2016/07/webperf

Server Timing

Server Timing, part of the performance timeline metrics, provides API access to request-response cycle performance metrics communicated from the server to the user agent.

Draft state: Working Draft

Expected completion: @@TBD was expected to be in CR in 2024

Latest publication: 2023-04-11

Exclusion Draft: https://www.w3.org/TR/2015/WD-server-timing-20150217/
Exclusion period began on 2015-02-17 and ended on 2015-07-17.

Exclusion Draft Charter: Produced under Working Group Charter: http://www.w3.org/2013/01/webperf

Long Tasks API

This document 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

Expected completion: @@TBD was expected to enter CR

Latest publication: 2024-05-24

Exclusion Draft: https://www.w3.org/TR/2017/WD-longtasks-1-20170907/
Exclusion period began on 2017-09-07 and ended on 2018-02-04.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2016/07/webperf

High Resolution Time

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

Draft state: Working Draft

Expected completion: @TBD level3 not yet in CR

Latest publication: 2024-11-07

Exclusion Draft: https://www.w3.org/TR/2020/WD-hr-time-3-20201001/
Exclusion period began on 2020-10-01 and ended on 2021-02-28.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2018/09/webperf/

User Timing

This specification defines an interface to help web developers measure the performance of their applications by giving them access to high precision timestamps.

Draft state: CRD

Expected completion: Maintained in CR

Latest publication: 2025-02-13

Exclusion Draft: https://www.w3.org/TR/2021/CR-user-timing-20211202/
Exclusion period began on 2021-12-02 and ended on 2022-01-31.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2021/02/webperf.html

Network Error Logging

This document 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 resources.

Draft state: Working Draft

Expected completion: @@TBD spec to be removed from REC track?

Latest publication: 2025-05-05

Exclusion Draft: https://www.w3.org/TR/2014/WD-navigation-error-logging-20140211/
Exclusion period began on 2014-02-12 and ended on 2014-07-12.

Exclusion Draft Charter: Produced under Working Group Charter: http://www.w3.org/2013/01/webperf

requestIdleCallback()

The requestIdleCallback method is a more appropriate way for scheduling background tasks during times when the browser would otherwise be idle.

Draft state: Working Draft

Expected completion:@@TBD new CR? was left to be integrated in scheduling APIs but not ready

Latest publication: 2025-05-21

Exclusion Draft: https://www.w3.org/TR/2017/CR-requestidlecallback-20170131/
Exclusion period began on 2017-02-02 and ended on 2017-04-03.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2016/07/webperf

Reporting API

The reporting API provides 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

Expected completion:@@TBD expected CR

Latest publication: 2025-06-11

Exclusion Draft: https://www.w3.org/TR/2016/WD-reporting-1-20160407/
Exclusion period began on 2016-04-07 and ended on 2016-09-04.

Exclusion Draft Charter: Produced under Working Group Charter: http://www.w3.org/2015/06/webperf

Largest Contentful Paint

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

Draft state: Working Draft

Expected completion: Expected CR @@TBD

Latest publication: 2025-09-11

Exclusion Draft: https://www.w3.org/TR/2022/WD-largest-contentful-paint-20220524/
Exclusion period began on 2022-05-24 and ended on 2022-10-21.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2021/02/webperf.html

Event Timing API

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

Draft state: Working Draft

Expected completion: @@TBD

Latest publication: 2025-10-17

Exclusion Draft: https://www.w3.org/TR/2022/WD-event-timing-20220524/
Exclusion period began on 2022-05-24 and ended on 2022-10-21.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2021/02/webperf.html

This document provides an interface for web applications to access timing information related to navigation and elements.

Draft state: Working Draft

Expected completion: @@TBD Integration into Resource Timing?

Latest publication: 2025-12-05

Exclusion Draft: https://www.w3.org/TR/2013/WD-navigation-timing-2-20130131/
Exclusion period began on 2013-01-31 and ended on 2013-06-30.

Exclusion Draft Charter: Produced under Working Group Charter:

Resource Timing

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

Draft state: CRD

Expected completion: Maintained in CR

Latest publication: 2025-12-09

Exclusion Draft: https://www.w3.org/TR/2022/CR-resource-timing-20221004/
Exclusion period began on 2022-10-04 and ended on 2022-12-03.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2021/02/webperf.html

Paint Timing

This document defines an API that can be used to capture a series of key moments (First Paint, First Contentful Paint) during pageload which developers care about.

Draft state: Working Draft

Expected completion: @@TBD CR?

Latest publication: 2026-01-07

Exclusion Draft: https://www.w3.org/TR/2017/WD-paint-timing-20170907/
Exclusion period began on 2017-09-07 and ended on 2018-02-04.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2016/07/webperf

Device Memory API

This document defines a 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

Expected completion: @TBD expected CR?

Latest publication: 2026-01-19

Exclusion Draft: https://www.w3.org/TR/2018/WD-device-memory-1-20180925/
Exclusion period began on 2018-09-25 and ended on 2019-02-22.

Exclusion Draft Charter: Produced under Working Group Charter: https://www.w3.org/2018/09/webperf/

Standards

List of Standards produced by the Web Performance Working Group.

This document provides an interface for web applications to access timing information related to navigation and elements.

Latest publication: 2012-12-17

User Timing Level 2

This specification defines an interface to help web developers measure the performance of their applications by giving them access to high precision timestamps.

Latest publication: 2019-02-26

High Resolution Time Level 2

This specification defines a JavaScript interface that provides the current time in sub-millisecond resolution and such that it is not subject to system clock skew or adjustments.

Latest publication: 2019-11-21

Other Deliverables

The Group maintains two non-normative documents:

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.

Timeline

  • Next meeting: TPAC 2026 in hybrid mode.

Success Criteria

In order to advance beyond Candidate Recommendation, each normative specification is expected to have at least two independent interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites. In order to advance beyond Candidate Recommendation, each normative specification must have an open test suite of every feature defined in the specification.

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 should be conducted via the Web Platform Tests project.

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

This group is expected to be guided by the following documents:

All new features should have expressions of interest from at least two potential implementors before being incorporated in a 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.
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 May 2025). 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-11-10 2025-12-01

No change in scope
Extended 2025-12-02 2026-04-30

No change in scope

Change log

Changes to this document are documented in this section.