WebPerfWG call - January 21st 2021

Participants

Noam Helfman, Nic Jansma, Tom McKee, Annie Sullivan, Sean Feng, Katie Hempenius, Benjamin de Kosnik, Steven Bougon, Nicolás Peña Moreno, Andrew Galloni, Ryosuke Niwa

Open Meeting around A/B testing - Feb 4th 12-2:30pm PST

Next call - Feb 18th

Resource Timing Tests - Tom McKee

Tom: Leading a project to increase test coverage to reduce amount of security bugs. Also want to clean up the tests
... Wanted to give a heads up to folks if anyone wants to get involved
Nic: Is the goal to have a proposal to replace the current tests?
Tom: More patching the current test suites, and covering more edge cases. Once the tests are in a consistent state, we can increase coverage
Nic: Github issue?
Tom: We have a doc, not sure if public. We can open an issue

https://github.com/w3c/resource-timing/issues/254

Nic: That’d be a good starting point.

BFCache proposal - Yoav Weiss

Yoav: We had previously discussed this at TPAC, more concrete proposal now
... We want to align metrics with UX, including BFCache
... Want to make these visible to RUM
... Fire new entries rather than override old ones
... Single time origin for all navigation
... Proposal: New NavigationTiming entry, queued on both PerformanceTimeline and PerformanceObserver
... Adding new NavigationType
... Not updating the L1 performance interface (performance.timing)
... NavigationType.back_forward_cache
... Spec changes: Queue a PerfNavTimingEntry from HTML's history traversal algorithm
... PaintTiming: New entry, back_forward_cache_paint, queued first paint after BF Cache happens
... Spec changes for indicating BFCache paint should be reported
... Plus updates to PaintTiming to use that flag
... Thoughts on First Input Delay.
... One option is to reduce the threshold of EventTiming entries after BFCache so it always appears. Similar to PaintTiming.
... Or we could file multiple "first input delay" entries. Might need compat research.
... Or we can file a new entry for "BFCache FID"
... For LCP, it's likely to be similar to the FP/FCP there, so probably don't fire it
Sean: For PaintTiming, have you thought about expanding existing FP to have an attribute mentioning it's bfcache instead of a new entry
Yoav: It's not a new entry type, it's still "paint" entryType but there will be a ".name=back_forward_cache_paint"
Sean: Another question I have, around reducing the threshold for FID, have you thought what the threshold would be? At TPAC we had discussed the threshold a bit and were concerned it was already too low in some cases.
Yoav: Not considering the threshold of good vs. bad FID, instead today we don't fire EvenTiming entries for every event, just the ones we consider slow (over 50ms). That threshold is possibly customizable up to a certain point. What I'm suggesting is after a BFCache we'll always fire an EventTiming entry, regardless of the duration of the event.
Nic: Are you aware of any analytics providers that monitor BF Cache today?
Yoav: Not aware of anyone today, if they did, they'd need to monitor pageshow/pagehide events
Nic: For the question of FID and how that looks, and you proposed a new entry to be able to monitor it. It seems reasonable for any analytics provider today that wants to start paying attention to bfcache events, then it's reasonable to ask them to listen to new events
Yoav: Main concern is that would be something unique for FID, the other ones are just new types.
Nic: You're saying for consistency the other ones just have new names
Nicolás: Name is used for the type today (event type, like 'mousedown')
Benjamin: For the LCP slide, and the note at the bottom about how we may want to tackle this in the future
... For me it seems safer to say we are going to refire all this stuff, instead of saying this may happen just for BFCache
Yoav: In the SPA navigation case, yes we may need to re-fire those. I'm not sure we have enough insight into what that may look like
... Concerned about solving a problem we don't fully understand here with LCP
... How will developers be able to distinguish from LCP for nav1 to LCP for nav2
... That would potentially change based on the shape of the API we decide for SPAs
... It's a problem we'll need to solve, and I don't think there are advantages to solving it now before it's relevant
Benjamin: Downside is we're introducing a special case for a special nav
... The path of least resistance is to re-fire and maybe re-fire for SPAs too
Nicolás: For LCP we can't just re-fire one entry, you'll need to iterate over all entries and use the largest one, so it would need to be a new entry type
Noam: Maybe add another property that indicates the type of LCP or timing
Yoav: Right now the current libraries that capture LCP (and the advice we give) is just to iterate over the array and the last entry is the LCP. Once we introduce new navigation, that will change.
... Maybe what we should do is think about way of changing that so future LCP entries would be compatible
Noam: So is the challenge to change the guidance?
Yoav: Challenge is for people to change their website to the new guidance. Webcompat changes are hard.
... If we were introduce a new type, we could tell people to look for the type or boolean, or use FinalLCP
Nicolás: Most analytics providers don't wait for unload so we're not going with FinalLCP
Ryosuke: One option would be to make it opt-in
Yoav: Equiv would be a new entryType that would be observed
Ryosuke: Or new global function to observe more types
Nic: Along those lines I'm wondering how many analytics packages actually track events post-pagehide-pageshow, since many may not be paying attention anyways
Yoav: Could use some research for that
Ryosuke: I echo Mozilla's viewpoint about adding a BFCache specific entry, assuming we make progress on SPA reporting a year or two for now, I think we need to figure out a solution that solves both.
... We should try to reduce the complexity of the buffer, not increase it
Yoav: At the same time, I don't think if we simply say LCP doesn't fire in BFCache cases, because it doesn't really make sense, I don't think it increases the developer complexity in this specific case. And we can add it later if we think it's reasonable to add.
Nicolás: Maybe it could be good to highlight how it would be extended for other navs like soft navs/portals.
Ryosuke: We need to have a consistent story here
Yoav: For the new NavigationType we're just adding a new entry
... For paint timing, we're adding a new entry name
... Neither seem to constrain us for future types
... For FID, we need to make sure whatever we do there is consistent with what we have with EventTiming. Favorable to fire whatever we have.
Ryosuke: I want to think about how other types fit into this picture
Annie: Maybe outside of this we could take any interested parties to think about how other navigation types could be represented here.
Nic: Sounds like a great idea, and we'd be interested as an analytics provider
Benjamin: Sounds good to think through a grid of the types what the differences are for these metrics
Yoav: Generally makes sense, the various performance entries have a consistency problem. For example, .name is used for different things in different entries.
... For web compat, we'll have a problem changing what we've already shipped
... Though that brings the N+1 problem where shipping a new thing always leaves the old thing behind
... Instead of using .name in one and .type in another, if we could use a single property that could be better
Nicolás: Ryosuke's idea to have a method, which is a mechanism so that they're always linked
Yoav: Entry Name is one of the biggest sources of inconsistency, for RT it's URL, for ET it's the event name
... Adding new entries is fine, but today we can't use a single attribute to denote it
Nic: We could add a new attribute that links to the NT entry it belongs to
Ryosuke: One edge case to consider if BFCache navigation happens while other forms of navigation are ongoing
Yoav: BFCache nav time would be after the start but before the end of a navigation
Ryosuke: It happens a lot
Nic: Not only bfcache navigation, but also possibly soft navs
... There could be overlapping navigation happening
Yoav: So idea to possibly point to specific NT entry might help
Nic: Seems like there's a balance between not confusing existing applications and being able to add data we want to support these scenarios. If we're really concerned about not confusing, the easiest way is to just add new things to pay attention to.
Ryosuke: Study between how different forms of navigation happen within a website. We need to have some sort of mental model.
... Make sure the API is such that if we get the data, we can discern different types of navigations
... So as to not get confused about which navigation the first paint is associated with
Yoav: A direct pointer may be a way to disambiguate that
... Would have to create new entries that people specifically observe
Ryosuke: For Soft Nav, if the user is on A and goes to B, and the user goes back to A, in abstract the page load of A "continued" while B was loaded, and A's requests won't necessarily be cancelled. Not all apps, but for some apps that may make sense
... We need to have a better understanding of how these navigation happen on each website and how they want to treat them -- what their models are
Yoav: I explicitly don't want to have to solve anything someone would want to do in the future in order to solve a problem we already understand well
Ryosuke: Would be useful to have a mental model for how all of those fit together