Enable developers to create and queue custom PerformanceEntry objects

[igrigorik]

(discussed at TPAC 2016; rough notes and summary of discussed ideas below)

User Timing provides a simple interface to create marks and measures. However, you can only customize the name, which limits its usefulness and flexibility: some developers have resorted to encoding complex values into the name (e.g. traceviewer), and we've had past requests to allow passing additional structured metadata via User Timing (see https://github.com/w3c/user-timing/issues/3).

---

Question: can (should we?) allow more developer control over creation of PerformanceEntries?

We could define a mechanism to create custom PerformanceEntries with arbitrary properties...

• Developers can define new and custom PerformanceEntry types to suit their needs; which could help with the SPA (https://github.com/w3c/charter-webperf/issues/27) and related use cases.
• Such entries would be automatically queued into performance timeline and be observable via PerformanceObserver -- i.e. RUM vendors can harvest them.
  • That said, allowing custom names may make things tricky for PerfObserver use case.. The observer needs to specify what it wants to observe; there will be a need for a registry/convention.
  • Should developers be allowed to create entries with same name as existing PerformanceEntry objects? E.g. "resource", "navigation", etc.
  • Attaching 'arbitrary metadata' sounds good in theory, but does it have runtime implications that we should consider? E.g. we don't want PerfObserver be saddled with transferring arbitrarily-sized large blobs of data.

[igrigorik]

A proof-of-concept polyfill by @tdresser: https://github.com/tdresser/input-latency-web-perf-polyfill/blob/gh-pages/performance_timeline_emit.js

[tdresser]

I've drafted a rough proposal here.

[igrigorik]

This is being incubated in: https://github.com/WICG/performance-entry. Let's direct any further discussions and comments to the WICG repo. Closing.