Re: WebPerfWG call - January 21st 2020 @ 10am PST

Minutes on Google Docs:
Github Minutes archive:

Copied here below as well:

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
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


   - Nic: That’d be a good starting point.

BFCache proposal
Yoav Weiss

   - Yoav: We had previously discussed this at TPAC, more concrete proposal
   - ... 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
   - 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
   - ... 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
   - 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
   - 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
   - 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
   - ... 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
   - 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
   - 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 <> wrote:

> Hi everyone!
> On the agenda
> <>
> 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
> <>
> .
> Join us <>!
> The meeting will be recorded and published online afterwards.
> See you soon!
> - Nic
> @NicJ

Received on Monday, 1 February 2021 22:00:21 UTC