- From: Nic Jansma <nic@nicj.net>
- Date: Mon, 1 Feb 2021 16:59:55 -0500
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAALun4v+93okvvGYddnJw0Cetv_kcbmXVw_Z6ZoMhxbH3vkEQQ@mail.gmail.com>
Minutes on Google Docs: https://docs.google.com/document/d/e/2PACX-1vRrWfK5IJ4OpdXokvbAaWvr8BmVlogJFghq6BSMGTZv276jZIBqM35nHEFRVOr7Xx0Gqy4i7dtpFzAm/pub Github Minutes archive: https://w3c.github.io/web-performance/meetings/ Video: https://youtu.be/oZGhdGzWJ2c Copied here below as well: Participants Noam Helfman, Nic Jansma, Tom McKee, Annie Sullivan, Sean Feng, Katie Hempenius, Benjamin de Kosnik, Steven Bougon, Nicolas Pena Moreno, Andrew Galloni, Ryosuke Niwa Open Meeting around A/B testing - Feb 4th 12-2:30pm PSTNext call - Feb 18thResource 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 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/254&sa=D&source=editors&ust=1612220248472000&usg=AOvVaw3brDsBSM2aRNLkSTLMzXlz> - Nic: That’d be a good starting point. BFCache proposal <https://www.google.com/url?q=https://docs.google.com/presentation/d/1-gckm8YTJfDnXa_Td8_mWbFDEITtH5CsKOoRKwg4JIM/edit%23slide%3Did.p&sa=D&source=editors&ust=1612220248472000&usg=AOvVaw1ubNK_j2jMKMqmgUOdU5HP> - 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 - Nicolas: 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 - Nicolas: 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 - Nicolas: 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. - Nicolas: 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 - Nicolas: 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 On Wed, Jan 20, 2021 at 10:04 AM Nic Jansma <nic@nicj.net> wrote: > Hi everyone! > > On the agenda > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz> > for our next call (Thursday January 21st @ 10am PT / 1pm ET) we will > discuss: > > - workerStart and navigation-timing > - BFCache > > The agenda is short at the moment, so if you have any additional items > you'd like to discuss, please add to the agenda > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz> > . > > Join us <https://meet.google.com/agz-fbji-spp>! > > The meeting will be recorded and published online afterwards. > > See you soon! > > - Nichttps://nicj.net/ > @NicJ > >
Received on Monday, 1 February 2021 22:00:21 UTC