v151 · performance · reporting

Declarative Performance Observer

A proposed Performance-Observer HTTP response header that asks the browser itself to record performance-timeline entries — navigation timing, marks, visibility changes — and deliver one consolidated report via the Reporting API when the session ends, even when JavaScript never ran or the renderer was killed.

Proposal stage. This is a pre-incubation explainer from the Chrome loading team (ChromeStatus status: Proposed). No Chrome channel processes the header yet, and there is no flag or origin trial to enable. The demos below send the real header from this server, exercise the real APIs the proposal builds on (PerformanceObserver, User Timing, visibility-state entries, the Reporting API report shape, fetchLater()), and honestly label everything the browser does not yet do.

concepts

  1. Header anatomy

    Build a real Performance-Observer header from live controls — entry-types checkboxes seeded from this browser's actual PerformanceObserver.supportedEntryTypes, a User Timing allowlist, and capture-early-failures — then fetch a server route that responds with it and read the negotiated headers back.

  2. Journey recorder

    Record a real session journey with today's PerformanceObserver — navigation, marks, measures, and live visibility-state entries — and assemble the explainer's exact application/reports+json payload from the entries this page actually captured, then POST it to the real reporting endpoint.

  3. The reliability gap

    See the gap the proposal closes: a live probe for the proposed session-end entry type, an abrupt-termination experiment where a killed worker's final beacon is provably lost, and the current best answer — a real, feature-detected fetchLater() deferred beacon.

why it is proposed

Every JavaScript observability API dies with the page. A DNS timeout means no script ever ran, an OOM kill on a low-end phone fires no pagehide, and unload handlers are deprecated because they break the back/forward cache. The proposal moves collection into the browser: a declarative response header activates recording at navigation time, and the browser delivers the consolidated report — including a new PerformanceSessionEndTiming entry — through the Reporting API after the session ends, surviving crashes and early network failures that today are invisible.

references