search

w3c / performance-timeline

Performance Timeline
https://w3c.github.io/performance-timeline/
Other
111 stars 34 forks source link

Should droppedEntriesCount be frozen on each observer? #181

Closed npm1 closed 3 years ago

npm1 commented 3 years ago

Currently the droppedEntriesCount keeps increasing on each observer callback, once the buffers become full. Could this be confusing to developers? An alternative to consider: freeze the count on the first nonzero value for each PerformanceObserver. This way you still know how many dropped entries occurred if the observer is too late, or when the buffer became full if the observer was early but the buffer eventually became full.

nicjansma commented 3 years ago

From an analytics perspective, my feeling is that most consumers of droppedEntriesCount will be mainly interested in reading it on the very first PO callback when they set buffered: true. For that reading of droppedEntriesCount, I would expect it to be reflective of whatever the status of dropped entries is at that time. I would probably then squirrel away that value somewhere, and include it on my beacon data so the backend knows how "complete" the view of my data is.

From that point on, I wouldn't care about any dropped entries, since my observer is active -- I'm getting all entries going forward, even if the buffer is full.

As a result, I'm not sure I would ever read droppedEntriesCount again, since my observer is side-stepping any potentially full buffer.

Could we only set it to a defined value (0 or [n]) on the first callback to simplify this? On subsequent PO callbacks, it's undefined?

I'm not thinking of any scenario where someone would want to continuously check the PO callback droppedEntriesCount, unless they were trying to actively determine the browser's buffer size for those entries. But anyone using a PO shouldn't really care, since they have their PO active right? It would only be useful for determining the browser internal limits. I'm not sure if we care enough to make that scenario possible?

npm1 commented 3 years ago

Hmm yea this is a good idea, thanks! Anyone else have thoughts?

sefeng211 commented 3 years ago

Changing it to undefined for subsequent callbacks sounds weird to me....

I think keeping it keeps growing could be useful if you want to get a total number of dropped entries for multiple observers at some point. What do we think about the renaming approach that Michal brought up?

No matter which way we go, we should update the spec to make it crystal clear about when we increase/freeze the value.

npm1 commented 3 years ago

We'll change the spec for sure, just need to decide what the behavior is going to be. The rename approach is to expose totalEntriesCount instead of dropppedEntriesCount, with the obvious semantic change right? This seems fine to me as it makes it clearer what the number is about, with the downside being that now the developer needs to look up the buffer size in the relevant user agent in order to determine the number of dropped entries.

sefeng211 commented 3 years ago

I thought the idea was to call it something like totalDroppedEntriesCount to hint the fact that it would keep growing?

npm1 commented 3 years ago

Ah hmm ok, I'm not sure if just adding total to the name is enough to dispel potential confusion around the fact that the entries are not really dropped.