Web Performance Working Group 2026 Charter

[nicjansma]

These are draft changes for the 2026 W3C Web Performance Working Group charter.

The existing 2023 charter will end on 01 June 2026.

1. Remove Two-Implementor Requirement for Features

There is a clause in section 4. Success Criteria that mentions a requirement of needing ... at least two intents to implement ... to add features to specs:

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

This wording was added into the 2023 WebPerfWG Charter, and we think this requirement impairs the speed of development and evolution of our specifications.

In some cases, features may be marked as intentionally optional (the User Agent may decide to support it, or not). Some examples of this are First Paint, and Resource Timing sizes + Delivery Type. As a Working Group, we have agreed these features can be optional.

In other cases, features may only have a single Intent to Implement at the time the feature is being proposed, but the feature will be built with the consultation of the Working Group, with the goal of attracting additional Intents to Implement as the feature evolves. An example of this right now is contentEncoding in Resource Timing.

Under the current charter text, specifications cannot be changed to add features until there are at least two Intents to Implement. As a result, other working models would need to be used to ensure new features can be discussed and specifications can evolve. Some of those options may be to have long-living open Pull Requests against the spec, or monkey-patching specs from another spec. We do not believe either of those working models are desirable.

Instead, if there is an indication that a new feature may only be supported by a single implementor in the short term, we will annotate the specification with a note that the feature is experimental.

We will be changing the wording to

New features that do not have support from at least two implementers will be incorporated into the draft specifications with an annotation of their experimental or optional status.

2. Single-Implementor Specs transition back to WICG

We have a few Web Performance specifications in section 3.1 Deliverables - Normative Specifications that are single-implementor:

• Long Tasks
• Device Memory

At this time, these specifications are only implemented in Chromium. We do not have Intents to Implement from other User Agents.

We still believe that the Web Performance Working Group is a good avenue to discuss these specifications. However, we think moving them back to an incubation state (under WICG) is appropriate. They have been moved to Past Deliverables.

3. Remove Web Performance Timing APIs Primer

The charter lists a other deliverable for a primer:

A Primer for Web Performance Timing APIs document to facilitate the understanding of the interrelationships between its deliverables.

The existing primer is out of date (not updated since July 2020), and we do not think the Working Group has the capacity to keep such a document fresh.

Instead, we think the documentation on MDN is more accurate and up-to-date.

We will remove a reference to this primer from the charter (in two places).

4. Removed HAR from Other Deliverables

We've removed text around exploring updates to HAR from 3.2 Deliverables - Other Deliverables, as we no longer intend to do this:

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

5. Updated Planned Work

There were a few mentions of Planned work: in the Charter. These have been updated to reflect their current status.

6. Update Participation section

Section 6. Participation mentions a few clauses in the To be successful... section that were clarified:

... expected to have ... active Editors and Test Leads for each specification.

We do not maintain a list of Test Leads for each specification, and rely instead on active Editors. "Test Leads" has been removed from this text:

... expected to have ... active Editors for each specification.

For this hours-per-week clause:

The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group.

We do not require a minimum weekly time contribution, and so we have replaced this text with:

The Chairs and specification Editors are expected to maintain regular contributions of their time towards the Working Group.

7. Update Communication section

Section 6. Communication mentions a few clauses that were clarified:

The meetings themselves are not open to public participation, however.

Meetings are open, but Chairs have moderation capabilities. The text has been updated to:

Meeting are open to the public and can be attended by any observer, at the Chairs' discretion.

8. Long Animation Frames Adoption

Per the 2026-01-16 email CfC - publishing Long-Animation-Frames as FPWD (closed on 2026-01-30 without objection), we are adopting Long Animation Frames into the Working Group's charter (and has been removed from the list of incubations).

9. Moving requestIdleCallback to HTML/WHATWG

Cooperative Scheduling of Background Tasks has been in a stable state for a several years.

We believe the best home for it is in the HTML spec, and plan to transition it to WHATWG.

10. Moving Beacon to Recommendation

Beacon has not had any active development and is supported by all major browsers.

We plan to move it towards Recommendation.

11. Element Timing Adoption

Per the 2024-11-22 email Call for Consensus - Adopting Element Timing (closed on 2024-12-13 without objection), we adoped Element Timing into the Working Group's charter (and has been removed from the list of incubations).

Other: Updated Incubations List

We don't include incubations in the charter; however, we list some in the README for our Github repo.

While outside the scope of these charter changes, this PR updates the incubations list.

[caribouW3]

To clarify on item 1, the W3C process requirements are at
https://www.w3.org/policies/process/#implementation-experience
<< Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized. >>
The draft 2026 charter has the default charter template wording.
Once we have entered Candidate Recommendation, we can't advance without interop for all features, except for features marked "at risk", or we need to request another CR. Careful review of implementation intent when entering CR avoids the issue, so it is seems that your proposal:

Instead, if there is an indication that a new feature may only be supported by a single implementor in the short term, we will annotate the specification with a note that the feature is experimental.

is already available without customizing that section of the charter.

[yoavweiss]

To clarify on item 1, the W3C process requirements are at
https://www.w3.org/policies/process/#implementation-experience
<< Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized. >>

Thanks! I don't see there any definition of what what "intent to implement" is or looks like.

What I do see is that the CR phase is there to enable gathering implementation experience in order to move specifications to REC.

The draft 2026 charter has the default charter template wording.

You mean 2023? If so, I have significant reservations about the way this language was introduced into the charter.

Once we have entered Candidate Recommendation, we can't advance without interop for all features, except for features marked "at risk", or we need to request another CR

I guess part of the annotation could be an "at risk" marking. We can also try to improve the process to better align this with reality. (e.g. "not yet interoperable", "in-spec incubation", etc.)
@cwilso - I'd appreciate your thoughts, if you have any.

[caribouW3]

Thanks! I don't see there any definition of what what "intent to implement" is or looks like.

The actual wording is the current charter draft is
"All new features should have expressions of interest from at least two potential implementors before being incorporated in a specification."
which is similar to "intent to implement", the goal being to be able to test interop before Recommendation.

The draft 2026 charter has the default charter template wording.

You mean 2023? If so, I have significant reservations about the way this language was introduced into the charter.

No, I mean the 2026 draft ,
which is exactly the text from the template.

[yoavweiss]

"All new features should have expressions of interest from at least two potential implementors before being incorporated in a specification."

I think this is exactly the part the Chairs want to change. Extensions to existing features that don't have multi-implementer interest just yet should be incorporated into specifications, while clearly annotating their status.

[caribouW3]

New Features are the class 4 changes described in
https://www.w3.org/policies/process/#correction-classes
(also when applying to a Rec: https://www.w3.org/policies/process/#revised-rec-features)

That specific wording in the charter template is meant for specs that stay in CR as "living standard", so new features can be added to a spec that already entered CR, but in the same way, they have to be tested for interop, therefore the need for 2 implementations in the end.
You seem to refer to other classes of changes.
In any case, marking at risk something that has interest from only 1 implementor is generally a good idea (it will attract attention of other implementors, or will be dropped).

[caribouW3]

I noticed that the charter draft here is not the one from the "charter refinement"
https://github.com/w3c/charter-drafts/blob/gh-pages/2026/webperf-wg-charter.html

[marcoscaceres]

With my WebKit hat on, the charter overall is moving in a good direction, especially around clarifying deliverables and aligning more closely with incubation.

I wanted to comment specifically on the proposed change to remove the expectation of support from at least two implementers before incorporating new features into specifications.

I understand the motivation here. In practice, it can be quite difficult to evolve specs when changes are blocked on multi-implementer signals, especially if it is hard to get everyone aligned on a steady cadence. That can lead to work stalling or being pushed into awkward patterns like long-lived PRs or parallel incubation that never quite converges.

That said, I am not convinced that lowering the bar for inclusion in Working Group specifications is the right way to address that problem. To me, this risks blurring the line between incubation and standardization, and could make it easier for WG specs to accumulate features that do not yet have a clear path to interoperability. The expectation of multi-implementer interest has historically been an important signal that a feature is ready to move from exploration into standardization.

I also find it a bit in tension with the decision to move APIs like Long Tasks and Device Memory out of active deliverables due to lack of multi-implementer adoption. That seems to reinforce the idea that WG-track work should reflect broader implementation interest, which I think is a good thing.

More broadly, I wonder if this change is compensating for a participation problem rather than addressing it directly. If we have too few implementers actively engaged in the group, then any bar that depends on multi-implementer signals will naturally be difficult to meet.

That is a harder problem to solve, and one that all of us likely share responsibility for, but I am not sure that relaxing the expectation is the right long-term answer.

It may be worth exploring ways of working that preserve the expectation of multi-implementer interest while making it easier to collaborate and make progress. Otherwise, there is a risk that we trade short-term velocity for weaker long-term interoperability outcomes.

It is also worth noting that this change does not appear to have been part of earlier charter drafts that were circulated more broadly (i.e., the one sent to the TAG), which may make it worth taking a bit of extra care in evaluating its impact.

[yoavweiss]

Thanks for reviewing our charter draft!!

I am not convinced that lowering the bar for inclusion in Working Group specifications is the right way to address that problem

That is not what we’re doing here. The wording in the current charter’s Success Criteria section says “All new features should be supported by at least two intents to implement before being incorporated in the specification.”

AFAIU, that’s a criteria for moving a specification to CR, not for e.g. an initial draft of a new feature. It might be worthwhile to clarify that part and make it more explicit.
Beyond that, “Intent to implement” is not a well-defined term, and currently not one that exists for any implementation. (Chromium now has “intent to prototype”)

The status quo in the WG has been that features that received enough support by participants (but not necessarily multi-implementer support) landed in the WG specs (just not in CR ones), without any clear annotation regarding their level of support.

Other features had “multi-implementer interest”, but not multiple implementations, due to prioritization by the different implementers.

What we’re trying to do is fix that situation by:

• Removing specifications of entire features that only have a single implementer and are unlikely to get more implementers, due to fundamental opposition (e.g. Device Memory) or better alternatives (e.g. Long Tasks).
• Allowing subfeatures that don’t yet have multiple implementations to land in the spec, but properly annotate them as such.
  • In conversations with the Team, “at risk” came up as the obvious annotation, but we want to improve on that to make the status clearer to both browser implementers and web developers.
  • Historically, sub-features that were unlikely to get multiple implementations were marked as “optional” (e.g. First-Paint). We want the charter to reflect that.

The alternatives to this approach that other WGs have taken are either eternal PRs or monkey patching specs. Both seem like a regression from clear annotation of the web exposed parts that aren’t yet interoperable, while maintaining all the relevant algorithms under a single document.

More broadly, I wonder if this change is compensating for a participation problem rather than addressing it directly. If we have too few implementers actively engaged in the group, then any bar that depends on multi-implementer signals will naturally be difficult to meet.

While more active participation is always welcome, I don’t think that this is the only problem here. One implementer is always bound to tackle certain problems first, and properly reflecting the state of implementations for these solutions seems like the right way to go.

As an example, we thoroughly discussed in the WG the issue of TTFB and Early Hints, reached consensus around a solution, but multiple implementations did not materialize until very recently (by an external contributor). We think it’d have been better if the feature was clearly marked as “has consensus, but not yet interoperable”. Hence the charter change.

It is also worth noting that this change does not appear to have been part of earlier charter drafts that were circulated more broadly (i.e., the one sent to the TAG), which may make it worth taking a bit of extra care in evaluating its impact.

Yeah, we recently had a discussion with the Team on the source of truth for the charter draft. We now have a PR up against the one the Team has been using that includes these changes.

[marcoscaceres]

This is really helpful context. I think I better understand the intent behind the change. I agree the status quo has not been particularly clean, and making the level of support for features more explicit is a good goal. Clarifying “intent to implement” also makes sense.

That said, I think my concern is slightly orthogonal to the CR vs draft distinction.

What this change seems to do (and this may be unintentional) is normalize a model where features with a single implementation, or without clear multi-implementer traction, can live in WG specs for extended periods of time.

As a concrete example, imagine a feature that has WG support and one implementation, but limited traction elsewhere. Under this model, it could live in the main spec, be well defined, and be exposed to developers while remaining non-interoperable for a long time.

Even with annotation, being in a WG spec carries weight. It influences documentation, tests, developer adoption, and dependencies in other specs. That creates real ecosystem costs and makes course correction significantly harder later. I am happy to share horror stories, and I am sure you have them too. We have been particularly cautious about this in the Digital Credentials API work, where we have tried to put policies in place to limit the collateral impact of late changes.

I can see the practical benefits here, especially compared to long-lived PRs. At the same time, I think it raises a question about where we draw the line between incubation and standardization, and how strongly WG specs should signal convergence.

More broadly, this may be reflecting a participation constraint or a working mode issue. If it is hard to get multi-implementer engagement on a steady cadence, any such bar will be difficult to meet. I am not sure that normalizing single-implementer features in WG specs is the right long-term answer to that.

It might be worth trying lightweight process improvements alongside this, such as clearer signals of implementation interest in PRs or periodic reviews of in-flight features, to help collaboration without changing the underlying expectations.

Overall, I support the goal of better reflecting feature status, but want to be careful we are not implicitly redefining what it means for something to live in a WG spec. That is the main concern.

The change clearly identifies a real issue, but I wonder if the better path is to develop practices that help avoid situations like long-lived PRs in the first place, rather than normalizing them in a different form.