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 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. -- 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.
