longtasks icon indicating copy to clipboard operation
longtasks copied to clipboard

PerformanceTimeline support

Open nicjansma opened this issue 7 years ago • 7 comments

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

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

nicjansma avatar May 31 '17 15:05 nicjansma

(commented on the other issue)

spanicker avatar Jun 01 '17 04:06 spanicker

@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.

igrigorik avatar Jun 19 '17 14:06 igrigorik

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?

tdresser avatar Jun 12 '19 16:06 tdresser

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.

npm1 avatar Jun 12 '19 17:06 npm1

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.

igrigorik avatar Jun 12 '19 19:06 igrigorik

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

npm1 avatar Jun 12 '19 19:06 npm1

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 https://github.com/w3c/longtasks/issues/41#issuecomment-511840374

nicjansma avatar Jul 16 '19 14:07 nicjansma