W3C Web Performance WG, 29 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: WebPerfWG call 2021 07 29 - droppedEntriesCount presentation

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

And we're on so nicolas take it away.

B

B

And you see the duck yep! Okay, let me zoom it.

B

B

We basically got some feedback. um Well, you have pointed out that the way we were considering shipping dropped entries count could be a bit confusing.

B

So first, let me explain what what it is just as a recap, since we've talked about it here before um so when you use performance observer, you can use the buffered flag to get entries that were created before you begin observing.

B

That but there is a limit to the number of entries that the user agent will store simply because we don't want to just keep storing forever, especially.

B

To prevent, like unbounded memory use of these entries and just in general, prevent too much memory from being occupied for when they're not going to be accessed by the website.

B

So we have a max buffer size and we have suggested numbers for each in the registry, um but developers have asked us to basically make it easier to know when these buffers have become full, as this could potentially be a problem in cases such as long-lived sites or cases where the site just loads, a lot of content or maybe well depending on what kind of entry, for example, for users naming.

B

If they load too many uh resources, then you could potentially hit that buffer limit or if you shift all the time, you could also potentially hit the layout shift buffer limit, for example.

B

So, in order to satisfy the use case, we worked on dropped entries count, which is basically provided by the observer callback.

B

Let's see so in the in the callback, when you receive entries, you would receive the draft entries count which just represents how many.

B

B

Are dropped for that observer, basically for the entries being observed by that observer, if that makes sense. um So what's the confusion, uh the confusing part about this? The potential problem is that if this number is surfaced on every callback, then it could be potentially confusing. If developers see that the account increases, even though they have been observing entries, because the way it works is that once your offer size is full, then it starts increasing.

B

So it's basically a value that is computed for each frame independent of the observer itself, so a developer that looks at it later on will be like. Why did I drop entries when my initial callback told me that I didn't drop any entries so given that the main use case is to.

B

Now, if you dropped entries before you started observing, then we considered just populating the value only in the first callback after the observed call from the performance observer.

B

So we partnered with webdev insights, which allowed us to survey web developers, um and so the service size was 272 developers and we tried to filter out those that are unfamiliar with the the concept of performance observer.

B

So I just I wanted to highlight some of the results we obtained from the from the survey.

B

So the majority 90 of the respondents who work with performance observers say that they're easy to work with, although 10 say they're hard.

B

Only 71 percent of respondents use the buffer flat, sorry, the buffered flag, with uh 50 52, using it sometimes which is interesting and only 19 using it always so. That's a interesting insight.

B

Yeah, I wonder if it's related to the fact that it's relatively new and they hear web compatibility issues with the flag or uh not sure. What's going on there, um then 87 percent of uh the people, responding to a question said that it would be moderately valuable to surface um what we're proposing, which is the number of entries that exceeded the buffer before the observer was registered.

B

And we also asked about the naming which we had a bit of back and forth in the uh in the tag review, and we found that the majority 52 percent found the the name we chose, which is dropped, entries count to be to be clearer and we compared that with something like total job. Then discount and total interest count.

B

So, basically, we were trying to do this survey to determine what is the clearest um way to surface the information so so that the developers that want to use it can tell us if certain buffer sizes are too big or too small, um and we we think that the best path forward is to ship the simpler version based on the responses that we're seeing, um because um this method is already a little bit sorry this. What this value is is already a little bit complicated to explain um and so like.

B

As you see, I took several minutes to explain what we're doing, and so we think we should just aim for simplicity, and so in the first callback we would expose a number and in subsequent callbacks we would basically just not expose it or basically, it would just return null or zero by the way.

B

um Obviously, unless you call observe again- which I guess is uh and this case because most of the time you just call observe once with an observer, but um so that that is the result of the survey and uh yeah, it might go.

A

Sorry, just on the topic of registering a second observer, um it might be an edge case.

B

A

Yeah just one second, let me I'll stop recording and then we can move over to the discussion.