1 of 8

Custom Performance Entries

Full proposal here.

2 of 8

Goals

  • Enable developers to dispatch custom performance entries into the performance timeline, which are observable via PerformanceObserver.
  • Enable rich annotation of custom performance entries.
  • Enable recording performance entries with arbitrary timestamps.

3 of 8

CustomPerformanceEntry

interface CustomPerformanceEntry : PerformanceEntry {

readonly attribute any detail;�};

4 of 8

QueueEntry

partial interface Performance {� void queueEntry(DOMString name,

optional DOMHighResTimeStamp startTime,

optional DOMHighResTimeStamp duration,

optional any detail);�};

5 of 8

What about mark & measure?

  • We could also extend mark & measure.
  • This doesn’t enable recording arbitrary timestamps.

partial interface Performance {� void mark(DOMString markName, optional any detail);�� void measure(DOMString measureName,� optional DOMString startMark,� optional DOMString endMark,

optional any detail);�};

​

6 of 8

CustomPerformanceEntry constructor

  • We could use a constructor for a CustomPerformanceEntry : PerformanceEntry, and pass CustomPerformanceEntry objects to queueEntry, mark and measure.
  • This is a bit awkward, as we’d need a version of mark & measure which didn’t take a name parameter, and only took the CustomPerformanceEntryObject.

7 of 8

Can we just polyfill it?

  • We can get mostly there (polyfill here).
  • This API is primary about defining the interface between web developers and analytics packages.

8 of 8

Namespacing

  • See doc for details on custom entryTypes vs this approach.
  • Not necessary for V1, but ideally consumers could listen to a subset of custom events.
  • Option: Pass list of string “tags” with mark, measure & queueEntry.
  • PerformanceObserver.observe takes list of tags, reports entries with all tags.
  • Call observe multiple times to report entries with any of a list of tags.