Allow creation of PerformanceObserver with flag to "emit timeline"? #41
Comments
|
This seems neat. One thing that feels undefined in this space, but important somehow, is how to allow some performance APIs to be defined s.t. they can insert events only when there is an observer. Frame timing, for instance: we want it to be off by default, but on when someone observes it. If you have a flag that says "absorb the items in the performance timeline," then it could make it very difficult for us to have frame timing off ever, because someone might sometime create a retro-active observer request. Food for thought. I agree that the use case is neat. I don't think the issue I'm talking about is really to do with the proposal at hand, more that this proposal brings out an underling vagueness in the overall performance timeline spec overall. |
What's an example? FWIW, we've said that PO entries are to be emitted only when they're 'finalized', which means that resource/navigation entries would be emitted once those fetches have finished -- tangent: we also discussed a potential route where we expose "partial" entries as standalone records. Assuming my page ships a script block that registers PO observer at the very top, what would I miss? |
|
Server timing marks? |
|
It could be possible to miss a resource timing from a prefetch header. Also.. imagine the following potential race (this may not be accurate with the currently specified process model):
It seems simpler to tie allow the following which removes any risk and removes the requirements for script block at the very top: |
|
@toddreifsteck it sounds like you're suggesting that Also, as @natduca noted, I don't think we can or should make blanket promises about "previous events" because we may not log them until they are requested - e.g. if no-one asks for frame timing events then we shouldn't incur any overhead until such an observer is registered. Last but not least, assuming we (a) don't clear the buffers, and (b) don't make any blanket promises about observing "previous events", I think the behavior you're looking for is trivial to implement as is: <html>
<script>
function processEvents() { ... your logic ... };
// process buffered events, if any are present...
processEvents(performance.getEntriesByName('resource'));
processEvents(....);
// subscribe to new events
var observer = window.performance.createPerformanceObserver(function(list) {
processEvents(list.getEntries());
}
observer.observe({typeFilter: ['resource', '...']});
</script>
....
</html> |
|
With a very minor race condition between the second |
|
@nicjansma true, but addressable if its a problem in practice: initialize observer first, then fetch current buffer and dedupe if/as necessary. |
|
Per 8/12 call, it may be useful to enhance PerformanceObserver in the future to allow something like this but.. the race itself is best solved by ensuring that insertion of entries into the Performance Timeline is part of the EventLoop. Closing this suggestion for now. |
If a site wants to use PerformanceObserver in place of the existing performance.getEntries() API, they will could encounter scenarios where it is impossible to get a PerformanceObserver created before some PerformanceEntries are emitted.
Would it be helpful to add a flag to the creation of PerformanceObserver that indicates the first event should include the existing performance timeline that match the specified filter?
This mechanism should allow PerformanceObserver to 100% replace performance.getEntries().
The text was updated successfully, but these errors were encountered: