Please provide an end milestone for this trial. (Note: please take into account that releases are switching to 2-week).
On Tue, Aug 4, 2026 at 3:30 PM Chromestatus <[email protected]> wrote: > *Contact emails* > [email protected], [email protected] > > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPerformanceAPIs%22> > > *Web Feature ID* > 4217 <https://webstatus.dev/features/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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > 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 > <https://chromestatus.com>. > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a72681c.c91ea2f1.3ad85a.01ad.GAE%40google.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a72681c.c91ea2f1.3ad85a.01ad.GAE%40google.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8RKNxCE9Xtt%2B%3DzdyAfmA1OGqnFkv5gXpvTnggGeMTyNA%40mail.gmail.com.
