Closed
Description
(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 w3c/user-timing#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 (Improve RUM observability and monitoring of single page apps #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.