Intent to Experiment: JS Self-Profiling Markers

[Chromestatus]

Contact emails

moni...@microsoft.com, victo...@microsoft.com

Explainer

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

Specification

https://github.com/WICG/js-self-profiling/pull/89

Design docs

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

Summary

The JavaScript Self-Profiling API lets a web application sample its own call stacks to measure performance on real user devices. This feature adds an optional marker field to each captured sample that identifies the type of browser activity running when the sample was taken: script, gc, style, layout, paint, or other. A trace normally shows gaps between stacks that cannot be interpreted, markers let developers attribute that time to browser work happening outside their JavaScript, for example distinguishing script execution from style recalculation, layout, or a garbage collection pause, making slow traces easier to analyze and optimize.

Blink component

Blink>PerformanceAPIs

Web Feature ID

4217

TAG review

https://github.com/w3ctag/design-reviews/issues/1251

TAG review status

Pending

Goals for experimentation

Validate that JS Self-Profiling markers provide actionable performance signal for large real-world web applications when collected from real users, and confirm the marker data flows correctly end-to-end through production RUM pipelines. Specifically, we want to learn: - Whether per-sample markers let developers attribute slow field traces to browser activity outside their JavaScript (rendering, style/layout, GC) and act on it. - Whether the sampled marker data is accurate and stable enough at production scale (real devices, real workloads) to drive optimization decisions. - Whether the API shape (ProfilerSample.marker) is ergonomic for existing self-profiling consumers to adopt with minimal code change. Interested partners include Excel Online, which will consume the trial to enrich its existing JS self-profiling telemetry, and Datadog, which collects JS self-profiling data as part of its RUM product.

Origin Trial documentation link

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

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics

Low. Markers add a single optional marker field to the existing ProfilerSample, no new API surface or call pattern. The main ergonomic subtlety is graduated disclosure: style/layout are available everywhere, while script, gc, and paint appear only in cross-origin-isolated documents. The same profiling code therefore yields different marker sets depending on the document's isolation state, which could surprise developers who expect the full set. This degrades gracefully, a missing/absent marker is simply interpreted as idle/unknown, so it does not break existing traces, and analysis tooling can treat markers as best-effort annotations

Activation

Low to moderate. The feature is a small additive extension to the already-shipped JS Self-Profiling API, so adoption cost is minimal for developers already using it. The main activation barrier is that the restricted markers (script/gc/paint) require cross-origin isolation (COOP: same-origin + COEP: require-corp), which some large applications cannot easily deploy. This is mitigated by exposing the safe style/layout markers in non-isolated contexts, so developers get useful signal even without COI, and by the Origin Trial allowing partners to evaluate the feature on stable before committing to isolation.

Security

Moderate, and mitigated by design. Some browser work is shared across documents in a process, so exposing it could leak cross-origin timing: gc is not attributable to a single origin, and paint could act as a proxy for the render time of cross-origin opaque resources that fail a TAO check. To mitigate, script, gc, and paint markers are gated behind cross-origin isolation, in a COI process the document can already observe process-wide signals (Spectre threat model, performance.measureMemory, WeakRef), so these markers add no new leverage. style and layout are exposed without isolation because their timing is already observable through existing DOM/CSSOM APIs (getBoundingClientRect, getComputedStyle), consistent with Long Animation Frames. Markers attributable to a document are only attached when that document is same-origin with the profiler. Security discussion is tracked in https://github.com/WICG/js-self-profiling/issues/61 (Chrome security reviewed the COI-gated design in 2021, the non-isolated style/layout exposure is under active review).

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Ongoing technical constraints

The restricted markers (script, gc, paint) remain permanently gated behind cross-origin isolation; only style and layout are exposed in non-isolated documents. Markers are best-effort, sampled annotations (≈10 ms interval), attached only when the responsible document is same-origin with the profiler — they are not a precise or guaranteed signal and must not be relied upon for correctness.

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/js-self-profiling/tentative/marker-vm-state.https.html

DevTrial instructions

https://github.com/victorhuangwq/js-profiler-markers-demo

Flag name on about://flags

--enable-blink-features=ExperimentalJSProfilerMarkers

Finch feature name

JSSelfProfilingMarkers

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40800459

Estimated milestones

Origin trial desktop first

152

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5201297767792640?gate=5361868559482880

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

Please provide an end milestone for this trial. (Note: please take into account that releases are switching to 2-week).

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a72681c.c91ea2f1.3ad85a.01ad.GAE%40google.com.