W3C Web Performance WG, 27 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: WebPerfWG call 2021 05 27 at 10 05 GMT 7

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

So today, I'm going to talk about um the usual topic, these days, which is uh web of apis for responsiveness, and I have my teammate humble who has been working with me on the basically explorations we're doing so far. um So first, let's reiterate the goal for everyone to be on the same page, about what we're doing here.

A

So currently the responsiveness metric that we have in our web vitals is first input, delay or fit and, as you probably are all well aware, it has a lot of issues, and so the main problems we're trying to address are that. First, it only captures uh the first input right.

A

So if uh a user interacts a lot with the page, uh we don't really look at those further interactions and then secondly, it only looks at the input delay, which does not really capture any work that the website does as a response to the input, because the delay only captures from the input timestamp to when the input is about to start being processed by the browser.

A

And thirdly, first import delay does not measure scrolling, which is one of the, if not the most common uh user. Interaction on the web right now, so, first, let's talk about what an events duration is, and here we just use the term duration, because it's what is used in the performance event, timing interface, even though the name is kinda generic.

A

But the way we define duration is it is the from event timestamp to the next rendering update. After event, handlers have run basically after the event has been dispatched.

A

So if you look at that diagram, it would be from the leftmost portion up to basically the first yellow star on the diagram notice that there is still work ahead of that star, because um there could be asynchronous work that is uh posted from event handlers.

A

uh There are many ways to post asynchronous work right, for example, you can just do something like a set timeout right uh and so that work will not be captured by that initial yellow star and that's what the diagram has in in red, but capturing that asynchronous work is very difficult and so right now we're focusing on just using the events, duration, which is the bare minimum of the amount of time it takes for the user to basically see any response to their interaction on the site.

A

So now that we've uh described more or less what the improvement will be over input delay. Let's talk about how we can consider multiple events across the page load, um so we so the problem of just looking at events is that you can have different number of events for each user interaction in the way that you, like, normally think of an interaction like tapping on something or pressing something on the keyboard. Things like that.

A

So, for example, uh for pressing on the keyboard, you just have key down key press key up uh most of the cases you can have some other events depending on the language you're using, but whereas clicks and tabs have a bunch of other like uh have more events associated with them right like pointer down printer up all the touch events, the mouse events, and if it's, if it's a tap, then the click event as well, and so we want to basically consider a tab and a keyboard to be basically in some sense, equally weighted or yeah.

A

And so. In addition, we want to like try to measure something that is uh user perceptible, which in this case is not the individual. Dom events, but instead is like the actual interaction that they did so for. For those two reasons, we want to look at the user interactions themselves which, um as the examples I've mentioned, uh can be keyboard and it can be a tab or a mouse click or well any click with a device, and also it can be a drag right.

A

So like moving uh from one place to another. Now for this interactions, we would like to define something similar to their duration, but they're not really events right, so they technically don't have a duration. So we need to define uh something about how much they take. So this is what I'm calling in the slides, the latency so think of it as just the duration, but for the user interaction.

A

um So here we're considering two options: one is using the maximum duration of any associated event and another is to basically consider the amount of time taken by all the durations of all of the associated events, so basically kind of a non-overlapping sum uh that the events can have overlapping durations right.

A

So obviously we wouldn't count that time twice.

A

So those are the two main options: we're considering uh also open to ideas. um So here is an example, a simple example: uh pressing a a key and releasing it. So you have the keydown and keypress handlers which are basically fired after the user presses the key, and in this example, the frame is presented before the user releases, the key and then there's another task where the key up handlers run and the frame is presented later for that user key release.

A

So basically, in this case we have a keydown duration, which is disjoint from the key up duration, um even though that's not necessarily always the case. It'll basically depend on timing. um So in this example, the the key down duration is slightly longer, as you can see in the diagram. uh So if, for example, the duration is 25 in in one and 15 for the other, then the latency could be considered 25 if we're using the maximum.

A

Of course, if we're using the sun, then it'll just be 40 right. So those are the two latency ideas we were considering now in order to compute this latency like as a web developer. um It's not really super easy to do right now. You can obviously use event timing to gather durations of each event, but there are some problems. First, we have a minimum duration threshold which right now, I think, is 16 or something so any event whose duration is less than that is not surfaced to the api.

A

um So you would basically need to rely on event counts, somehow to make sure that you count those durations properly um and basically it becomes really hard to basically match events that correspond to the same user. Interaction right because you only are receiving the dumb events you got. um You basically have to figure out how to match them and group them into the user interactions they correspond to. So you can kind of try to estimate that by using the event timestamps, but as you can imagine, it's not really an easy process.

A

So that's why I have been proposing interaction id which I've talked about before, which is basically a new attribute to performance, even timing interface, where you could have an id that is exposed to the entry itself, so that the browser does the work for the developer. In terms of saying it's in terms of grouping entries that correspond to the same user, interaction uh in the sense that we defined previously, so those are the two proposed changes. I guess one would be no minimum duration threshold um and the other is the interaction id now.

A

In terms of the other big addition to for simple delay, we have scrolling right, which is not exposed at all.

A

So in order to enable developers to measure scrolling, we want to basically expose the scroll agency for because, because right now, it's not really something that is easy to measure or that the the order that is exposed, the event timing, um and so first we need to define what about scrolling do we want to expose so for the purpose of this metric?

A

In particular, we want to define the latency as just the initial scroll update latency, which means, from the event timestamp of the first event that made this actually become a scroll right to the first rendering update after after that and notice. That e scrolling is a bit different right because there's not really any dumb events associated with the this latency in chrome and assume, probably most modern, browsers. The scrolling can be uh performed without having to go to the javascript thread, and so for that reason it's not blocked on any dom event handlers.

A

So that's why we need to define the latency directly.

A

So in terms of the web perf apis that this would require well, we basically need something that tells us that the scroll latency right so two ideas there one would be have a new performance event. Timing entry, which has.

A

A name which is scroll or scroll begin. The name right now is the event type. So this would be just basically a made up event type so that we can expose the scroll latency we want there. The other option is to just have a scroll timing: api where.

A

We expose the latency we want and it's the benefit is that it. It is perhaps nicer to augment in the future right since it's not tied to the interface shape of every other event type. The downside is that it's yet another new api right so would welcome thoughts on which of those two options are preferable, um and that is the end of my slides. So I guess: should we stop the recording here or yeah that people can chime in you.