Determining if the buffer was full when using the buffered flag

[nicjansma]

When using PerformanceObserver with the buffered: true flag, it would be useful to know if that buffer was "full" when the buffered data is delivered.

Example:

const resourceObserver = new PerformanceObserver(list => {
  if (list.bufferFull) { // <--- can we get something like this?
    // take some action to note the buffer may not be the complete picture
  }
  list.getEntries().doSomething();
});
resourceObserver.observe({type: "resource", buffered: true});

This kind of flag would help with knowing if the data being fetched is the complete picture, or just a partial view as a result of fetching the PO entries too late. For example, when third-party analytics load later on the page (to avoid affecting the page load time), if we know the buffer we're querying was already full, we can mark it as "incomplete" in our analytics and/or help the site owner increase the buffer size if desired (e.g. for ResourceTiming specifically).

While it might be possible to infer that the buffer you're retrieving is full by noticing that it is at a well known length (e.g. 150 or 250 entries in the case of ResourceTiming), I think in practice this would be error-prone:

• Different entry types have different max buffer sizes (e.g. 250 for ResourceTiming, 200 for LongTask)
• Different UAs may have different buffer sizes for the same type (e.g. Internet Explorer has a 500 ResourceTiming buffer size instead of 150/250, Firefox at one point had a max buffer size for UserTiming)
• Specs may update over time and change the buffer size (e.g. ResourceTiming increased from 150 to 250)

[npm1]

The feature request makes sense to me! Things I'm not so clear about:

• Is this something you have noticed frequently occurring in the wild? If it is then it may point to insufficiently sized buffers.

• Not sure what the best API to signal this would be. The list could indeed have a method stating whether the buffer was full at the time the observer callback occurs, but that seems a little strange since it seems to have nothing to do with the list. One alternative would be performance.isBufferFull(type) (or something like that), so that can be queried the first time the observer callback occurs. Another option is adding a third parameter to the callback (it seem this would be backwards compatible, maybe?).

[nicjansma]

• We saw this frequently with ResourceTiming and when those buffers were capped at 150 entries in some browsers. But I could see it being more useful as we add more diverse entry types to the timeline.

• On the W3C WebPerf call today, we discussed some possible ways of exposing this data, including those options from @npm1 above. One challenge is that if someone is requesting multiple types in the same Observer, we would either need to return a list of full buffers, or, we could just have a "at least one of these buffers was full" flag.

@yoavweiss also brought up that the signal that we're looking for isn't necessarily the size of the buffer or whether it's full, but whether there were any dropped entries for the buffer.

So the proposal would be to have a flag (or flags) (or API) that exposed whether that buffer had dropped entries.