Participants
- Yoav Weiss, John Engebretson, Dan Shappir, Pat Meenan, Nic Jansma, Carine Bournez, Sean Feng, Jeremy Roman, Steven Bougon, Ian Clelland, Alex Christensen, Corentin Perscheloche, Marcel Duran, Benjamin de Kosnik,
Admin
- Skipping Feb 17
- Next meeting: March 3 @ 8am PST / 11am EST / 3pm UTC
- Meeting shifted to be earlier every other time
- See how that goes and gather feedback
- EventTiming and LCP adopted into WG and moved over
Minutes
https://github.com/w3c/navigation-timing/issues/163
- Jeremy: working on prerender and prefetch
- Focus on making it possible to tell when a document was prefetched
- Telling the server as well as notifying the client side
- A lot of other things around prediction, and making sure that it’s consistent with cache partitioning
- Also on how it can work with IP anonymity
- Work being done on prerendering on specifying what the behavior in the document should be when the document is prerendered
- Today focused on distinguishing if the document was prefetched
- Useful to be able to know this is why the navigation was fetched
- May also be related to their business metrics, and can be useful to collect
- The simplest take on this is to add a boolean to the PerformanceNavigationTiming interface
- Not a natural place to extend it in the future, but doesn’t exclude it either
- Another idea is to have a separate entry and a `prefetchedUsed` boolean
- Maybe we can think of it as a separate resource fetch, rather than something related to the navigation
- Increases risk as it adds more info
- Dan: why on navigation and not on resources?
- Jeremy: Facility to allow knowing if a navigation resource was prefetched, due to the previous page or the browser initiating it
- Dan: bringing it up because I’m seeing scenarios where the resource to prefetch for the next navigation would be not the document but a large JS
- … so could be useful boolean on other resources
- Jeremy: That would be complex with storage partitioning
- … Some of the risk for cross-origin scenarios, is it provides an avenue for a site to pass information using multiple prefetches
- … heard from developers that losing the ability to prefetch a subresource has impacted their performance. But it’s hard to figure out the right way to do this
- … fetch in another partition or an uncredentialed fetch that’s visible from another partition
- … So would be interesting to solve this more generally, and maybe we should anticipate it
- … Another problem is that the previous page can prefetch a subresource and be wrong. Can we surface that?
- Dan: Currently considering implementing that and effectively prefetch subresources
- … Without going into the question if it’s the right thing to do, if it’s right for navigation, it’s right for resources
- … Otherwise, if we’re looking at impact on performance, the bit of info people want to know is caching state rather than prefetch state. So, why not expose cache state in general
- … Also, wanted to point out that prefetching can have an impact even if you didn’t get the full effect: e.g. started but haven’t finished prefetch, or prefetch after a long while once the resource is evicted, but the prefetch had positive side effects (e.g. preconnect)
- Jeremy: So for those extra bits of info, maybe a single boolean will not be sufficient, but we may need more bits: did it complete? Did it expire? Etc
- Dan: Need to think about it a bit more
https://github.com/w3c/navigation-timing/issues/154
- Nic: May need to consider multiple navigation
- Yoav: first step is to figure out what’s the missing properties in the L2 interface
- Nic: AI to research and update Github issue
https://github.com/w3c/longtasks/issues/76
- Yoav: Can take an AI to make sure it happens.
- Dan: Should sync XHR and alert count as a long task?
- Yoav: It’s a task and it’s long
- Dan: With `alert()` you get what you’re asking for. Is it worth the effort?
- Yoav: The effort is mainly to test this, regardless if we count them as long tasks or not.