v153 · self-profiling markers
The field itself, and the header it needs
Two questions, both answered by trying: can this page construct a Profiler at all, and does a sample from it carry a marker. The first depends on a response header, which is why the second cannot be asked from a file on disk.
What this page can do
The header, and what happens without it
This page is served with Document-Policy: js-profiling. Press the button and a frame is created that is not — an srcdoc document inherits no response headers — and it tries the same constructor.
This is deliberately behind a button because the attempt is not silent: Chrome writes a document policy violation to the console, which is the browser telling you the truth in the only place it can. A page that made that noise on load would look broken rather than instructive.
The failure is an exception at construction, not a silent empty trace — measured here as NotAllowedError: Failed to construct 'Profiler': JS profiling is disabled by Document Policy. That is the right design: a page that cannot profile finds out immediately rather than shipping a monitor that reports nothing. It does mean the API is unavailable to anyone who cannot set response headers.
The marker vocabulary
| marker | seen in a real sample? | what it means |
|---|
The "seen" column is filled only from values that appeared in a trace this browser produced. A value the proposal defines but this browser never emitted stays "no" — the table is a record of what happened, not a checklist of what should.