Specification

https://github.com/WICG/js-self-profiling/blob/main/markers.md, https://github.com/WICG/js-self-profiling/pull/89

Explainer

https://github.com/WICG/js-self-profiling/blob/main/markers.md

Links

• Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/366
• An introduction to the feature, aimed at unfamiliar audiences: https://github.com/WICG/js-self-profiling/blob/main/markers.md#introduction
• A description of the problems that end-users were facing before this proposal: https://github.com/WICG/js-self-profiling/blob/main/markers.md#introduction
• Alternatives considered: https://github.com/WICG/js-self-profiling/issues/61
• Examples of how to use the proposal to solve the end-users' problems: https://github.com/WICG/js-self-profiling/blob/main/markers.md#key-scenarios
• What do the end-users experience with this proposal: https://github.com/WICG/js-self-profiling/blob/main/markers.md#introduction
• User research you did to validate the problem and/or design, if any: N/A — validated with partner developers (Excel Online, Datadog) via an upcoming Chromium Origin Trial rather than formal user research.
• Web Platform Tests: https://wpt.fyi/results/js-self-profiling/tentative/marker-vm-state.https.html
• Security & Privacy self-review (W3C questionnaire): https://docs.google.com/document/d/1SYveOkhEdx2hvUdVItc9SjADwOF7bIpp_IvXk9hS-Tc/edit?tab=t.0

The specification

• Follows the Web Platform Design Principles.
• Includes Security and Privacy Considerations sections based on answers to the Security/Privacy Questionnaire.

Where and by whom is the work is being done?

• GitHub repo: https://github.com/WICG/js-self-profiling
• Primary contacts:
  • Monica Chintala (@monica-ch), Microsoft, Origin Trial lead
  • Andrew Comminos (@acomminos), Meta, base JS Self-Profiling API editor
• Organization/project driving the specification: Microsoft (Microsoft Edge)
• This work is being funded by: Microsoft
• Primary standards group developing this feature: W3C Web Performance Community Group / WICG
• Group intended to standardize this work: W3C Web Performance Working Group
• Incubation and standards groups that have discussed the design:
  • WICG (Web Incubator CG) — proposal, IDL, and cross-origin exposure discussion: https://github.com/WICG/js-self-profiling/issues/61 and https://github.com/WICG/js-self-profiling/pull/89

Feedback so far

• Multi-stakeholder feedback:
  • Chromium comments: Positive — driving the implementation and Origin Trial. ChromeStatus: https://chromestatus.com/feature/5201297767792640
  • Mozilla comments: No signal yet. The base JS Self-Profiling API is not implemented in Gecko; no standards position has been requested for the markers extension.
  • WebKit comments: No signal yet. The base JS Self-Profiling API is not implemented in WebKit; no standards position has been requested for the markers extension.
  • Developer/implementer feedback: Interest from RUM/self-profiling consumers — Excel Online (Microsoft) and Datadog — who plan to evaluate the feature via the Chromium Origin Trial.
• Major unresolved issues with or opposition to this specification: None known. The one open design point is the cross-origin-isolation gating of the sensitive markers (script/gc/paint), under active security discussion in https://github.com/WICG/js-self-profiling/issues/61. No opposition has been raised.
• Status/issue trackers for implementations:
  • Chromium: https://chromestatus.com/feature/5201297767792640 and crbug.com/40800459
  • Spec PR: https://github.com/WICG/js-self-profiling/pull/89

You should also know that...

1. This is an incremental extension of an already-reviewed, shipped API. The base JS Self-Profiling API went through TAG review in #366 and ships in Chromium. This proposal adds exactly one optional field — marker on ProfilerSample — labeling the user-agent activity at each sample (script / gc / style / layout / paint / other). No new entry point, no new way to start profiling, no change to the existing Document-Policy: js-profiling gate.

2. The only new consideration is timing, and it's addressed by design.

   • The full marker set is exposed only in cross-origin-isolated documents (COOP+COEP) via [CrossOriginIsolated] on the IDL member — the same isolation boundary already used for cross-origin-sensitive timing. In such a process a document can already observe process-wide signals (Spectre threat model, performance.measureMemory(), WeakRef), so gc/paint/script add no new leverage.
   • In non-isolated documents only style and layout are exposed. That timing is already same-origin observable today via forced synchronous reflow (Element.getBoundingClientRect() forces layout; getComputedStyle() forces style/layout). The markers provide the same class of information, sampled rather than forced — strictly less capability than pages already have. This mirrors the exposure model of Long Animation Frames (LoAF).
   • Markers attributable to a specific document are attached only when that document is same-origin with the profiler.

3. Timing / ask. We plan a Chromium Origin Trial to gather field data from partners (Excel Online, Datadog). Feedback before or early in the trial would be most valuable; we're happy to iterate on the marker vocabulary and gating as part of standardization.

<!-- Content below this is maintained by @w3c-tag-bot -->

---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1251