feat(core): add emitPerformanceMetric bridge for runtime telemetry

[vanceingalls]

Summary

Extend the runtime analytics bridge with a numeric performance metric channel. Hosts subscribe via the existing postMessage transport (one bridge, two channels) and aggregate per-session p50 / p95 for scrub latency, sustained fps, dropped frames, decoder count, composition load time, and media sync drift before forwarding to their observability pipeline.

This is the foundation other perf tooling sits on — the player itself emits the events; player-side aggregation and flush land in a follow-up.

Why

Step X-1 of the player perf proposal. Today there is no way for an embedding host to learn that scrub latency spiked, that a composition took 3 s to load, or that the media-sync loop is running 200 ms behind real time. The only signals are anecdotal user reports.

A single shared bridge keeps the runtime → host surface area minimal: hosts that already wire up the analytics channel get perf for free, and hosts that don't aren't paying for it.

What changed

• New emitPerformanceMetric(name, value, tags?) helper in @hyperframes/core that forwards a { type: "performance-metric", name, value, tags } envelope through the existing analytics postMessage transport.
• Six initial metric names defined in the proposal:
  • scrub_latency_ms — wall-clock from seek() call to first paint at the new frame.
  • playback_fps — sustained rAF cadence during play.
  • dropped_frames — count of >25 ms gaps within a play window.
  • decoder_count — number of concurrently-decoding video elements.
  • composition_load_ms — navigation-start to player-ready.
  • media_sync_drift_ms — drift between expected and actual decoder time.
• Each emit also writes a performance.mark() with { value, tags } on detail, so the same numbers surface in the DevTools Performance panel's User Timing track for local debugging without instrumenting the host.
• Zero PostHog (or any other analytics SDK) dependency in core — the host decides where to forward the events.

Test plan

• Unit tests cover the envelope shape, the performance.mark mirror, and the no-op path when no host has wired up the bridge.
• Manual: verified marks appear in the User Timing track when scrubbing the studio preview.

Stack

Step X-1 of the player perf proposal. Foundation for the perf gate (P0-1a/b/c) — the perf scenarios in this stack instrument these same channels for CI measurement.

[vanceingalls]

• perf(player): scope MutationObserver to composition hosts #395 : 2 dependent PRs (#396 , #428 )
• perf(player): share PLAYER_STYLES via adoptedStyleSheets #394
• feat(core): add emitPerformanceMetric bridge for runtime telemetry #393 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[jrusso1020]

Clean bridge. Additive, no breaking changes, everything downstream of postMessage is guarded. Test coverage is exactly what I'd want to see for a telemetry path — nulled transport, throwing transport, throwing performance.mark, zero/negative values, tag normalization, and a DevTools User Timing assertion when the environment supports it. Nice.

The double-guard (both performance.mark and postMessage wrapped in try/catch) is the right shape for runtime code that must never affect playback. One small non-blocking observation: the RuntimePerformanceTags type duplicates RuntimeAnalyticsProperties — may be worth collapsing to a shared alias in a followup if any third shape gets added, but carving them apart now is also fine since the semantics genuinely differ.

Approved.

— Rames Jusso

[vanceingalls]

@jrusso1020 — thanks for the careful read. One observation, intentionally deferred:

the RuntimePerformanceTags type duplicates RuntimeAnalyticsProperties — may be worth collapsing to a shared alias in a followup

Agreed it's worth revisiting. The two shapes share keys today but the semantics genuinely diverge — RuntimeAnalyticsProperties carries event-shaped attributes (cardinality-bounded for analytics warehouses), while RuntimePerformanceTags carries measurement-shaped attributes (used as DevTools User Timing detail and as PerformanceObserver-friendly key/value pairs). Folding them into a shared alias today would force one shape to inherit the other's constraints. Tracked as follow-up; will collapse once a third consumer arrives and the common subset is forced.

Nothing else outstanding here.