Participants
Dan Shappir, Noam Helfman, Rafael Lebre, Alex N.Jose, Pat Meenan, Nic Jansma, Yoav Weiss, Ian Clelland, Michal Mocny, Hao Liuk, Barry Pollard, Amiya Gupta, Carine Bournez, Benjamin De Kosnik
Admin
Nic: Next meeting - August 4th 10am PT
.. TPAC is September 12-16
… Meeting on Mon, Tue, Thu, Fri
… WIP agenda
… Add yourself to the attendees list
… Still capturing what people want to talk about
… Please add proposals near the top
… Registration is now available - need to be a WG member or invited expert
… Planning on being a hybrid meeting
… Organizers purchased some remote-friendly equipment
Yoav: Unload beacon is heading toward an Origin Trial
… provide feedback at https://github.com/WICG/unload-beacon
Minutes
BFCache restoration entry
Ian: Short update.
… issue 182 on performance timeline
… Resolution was that we want a different entry type
… Tie them all together with the concept of navigation id
… Can bikeshed the name
… Want to encapsulate the timing of the page show event
… Looking for feedback on the API shape
… Are there additional fields we should capture?
Nic: What duration will be set in this case?
Ian: Defined on performance entry directly
Nic: So duration is from the start of the user-initiated navigation to the end of the pageshow events being completed?
Hao: Defined as a performance entry, and the start time would be the navigation start
Nic: Navigation ID - this would be the first use for this? Is it an auto incrementing number? Unique ID?
Ian: Currently auto-incrementing number, starts with 1 for BFCache and SPA navs in the future
… Point to be made that an unguessable token would be better. When we’d introduce SPA navs, we don’t want to break people’s expectations.
… makes testing this more difficult
Nic: One thing seen in the field data, not every telemetry makes it to the backend
… incrementing beacon numbers can help us spot cases where telemetry is missing
… May be able to notice this otherwise, so may not be applicable
Michal: Does that increment across page loads?
Nic: yeah. Slightly different concept, but may be relevant.
Michal: Navigation ID is separate?
Ian: yeah
Nic: And other things link to this concept of navigation ID?
Ian: That’s the thinking. Allows you to tie entries together.
Nic: thinking through the duration - nice to have the breakdown of page show. Any other interesting breakdowns we could expose here?
Ian: I suspect it’s mostly browser internal, there’s some delay involved in retrieving the page from the cache that's unavoidable. From the start of the navigation, there may also be the time required to process any pagehide handlers on the previous page, which we certainly cannot expose.
Yoav: Regarding the entry’s name, it was an empty string (the first), because there’s no way to meaningfully name one bfcache registration vs another. So we wouldn’t want to support getEntriesByName() at all
Ian: One other type that doesn’t have a name
Hao: If you do getEntriesByName in JS, you get no result. So we shouldn’t implement it
Nic: Will we have getEntriesByNavigationId?
Ian: There was a proposed method. I should dig it up
Michal: useful solution for a question I had. If I care about event timing but want to slice it by navigations. I’d have to go through all navigation.
… But just the first event with this navigation ID should be what I want.
… So I’d just want the filter
Yoav: Why won’t filters work?
Michal: I’d have to listen to every possible type of navigation entry in order to do that.
Hao: So you’d have to know which navigation type incremented the navigation ID counter?
Michal: if all I care about is event timing, and this event had a navigation ID, I’d have to go back and find the thing. I’d have to build my own timeline in parallel.
… But if a new tpe of navigation entry is added, my script becomes stale
… but getByNavigationId would help me
Yoav: answered my question
Ian: LCP spec says that LCP has an empty name
Nic: Layout shifts may be the same
Yoav: makes sense to not support getEntriesByName for them
Hao: tried it and it returns nothing
Nic: There’s the new navigate API, would that add entries to that?
Michal: wouldn’t by default. It’s a cleaner way to use the browser’s API, but it won’t by default change the perf timeline
Ian: Talked to Domenic about this, and it’s outside of scope for the navigation API
… We may leverage parts of the API to inform the heuristics for what triggers an SPA navigation entry to be emitted, but that API doesn't attempt to define what is and is not an SPA navigation.
Michal: Not all uses of the navigation API are guaranteed to be a soft navigation
… the API makes it easier for frames to manage state. But that doesn’t mean they are “navigations”
Nic: found the discussion
Michal: Any way that unload beacon should play together?
.. I guess I’m not sure how it works with BFCache
Ian: unload beacon triggers when the page is in BFCache and not coming back
.. so restoration would cancel the beacon’s timeout if set
Nic: And the page can choose to add to the pending beacon.
Ian: No direct interaction between them
Michal: For some of these things you may want to slice, but that’s a convention.