PerformanceTimeline support

[nicjansma]

Right now, I think this is the only spec that has PerformanceObserver support but not PerformanceTimeline support (see w3c/performance-timeline#78).

Is that intentional? Could we get this data in the Timeline, possibly with a buffer like ResourceTiming/ServerTiming do?

[spanicker]

(commented on the other issue)

[igrigorik]

@spanicker which other issue? :-)

In the meantime, a few thoughts:

• we need to update processing algorithm — specifically where we call "queue the entry" — to toggle the optional "buffered" flag, to enable PerfObserver's to harvest entries queued before onload.
• we don't need to define any separate buffers for LT, the above should take care of the before onload cases, and everything after that is already covered by PO.

[tdresser]

Nic, is the buffered flag sufficient for you? We're hoping to gradually deprecate the PerformanceTimeline, to encourage folks to migrate to the observer API.

You mentioned yesterday that buffering until onload isn't sufficient.
Do you think we should keep buffering until the buffer is full?

[npm1]

To answer the question, it is intentional because of the performance overhead of monitoring longtasks (not sure if this is still applicable on Chrome at this point...). Thus, we do not have timeline support because otherwise we would need to monitor always. Note that the buffered flag won't work for longtasks, precisely for the same reason. This needs header registration unless we can prove that the performance overhead is not too bad, and in that case we can have them in the timeline or via buffered flag.

[igrigorik]

This needs header registration unless we can prove that the performance overhead is not too bad, and in that case we can have them in the timeline or via buffered flag.

Who can help validate the cost question?

FWIW, I remain skeptical of the header registration approach: in theory, it makes sense, but deploying it in practice is really hard for site owners (e.g. feedback from f2f RUM implementers "~10% of our users might be able to") and I suspect this brings us back full circle to the "browser should buffer some amount by default" discussion.

[npm1]

Ok, let's validate the cost question within Chrome and then come back to this with a decision.

[nicjansma]

Yeah, if LongTasks supported by-default buffering and the buffered flag, I don't think we'd need PerfTimeline support.

But, I understand the overhead concerns -- looking forward to hearing more.

Posted some additional notes in #41 (comment)