Re: WebPerfWG call - December 6th @ 10am PST

Thanks all for joining the call last week.

A recording <>
of the call as well as the minutes
are now available. Posting the minutes here for safe keeping:

WebPerfWG call - December 6th 2019

Alex Christensen, Steven Bougon, Ilya Grigorik, Giles Dubuc, Nic Jansma,
Yoav Weiss, Philip Walton, Subrata Ashe, Philippe Le Hegaret, Warren
Maresca, Annie Sullivan, Nicolás Peña

Upcoming Meetings

   - Doodle to figure out best times for calls:


   - Ping Privacy Request Reviews:

   - Resource Timing:
   - Performance Timeline:

Largest Contentful Paint

Annie Sullivan

   - Why are body background images invalidated as candidates for LCP?

   - Above shows examples where the body's background images are/aren't
   used in LCP calculation, and how the LCP calculation would differ

   - Couldn’t find great examples for the “splash screen” element removal
   heuristics so will re-evaluate and bring back more data in January
   - How does LCP correlate with other performance metrics in the lab?

   - Correlation study w/ Speed Index

   - Shows a good correlation w/ Speed Index

   - Also vs. First Contentful Paint (FCP) -- some cases where FCP=LCP, but
   many cases where FCP > LCP (as expected)


   - Gilles: basically asked for this so thanks for that work. Correlation
   with SpeedIndex is particularly interesting. Makes it sounds really
   - Benjamin: Agreed. This is great.

Issue TriageNavigation Timing

   - Add a new entry type for navigations from the BFCache

   - Philip: Proposal to have a separate navigation entry type dispatched
   when a page comes out of BFCache, to avoid updating existing timing data.

   - Ran tests that showed different behavior in Firefox and Safari that
   update the existing entry

   - Yoav: Chromium is catching up on the BFCache front so would be good to
   clarify behavior.

   - Do we want to add a new entry type, or can we just another entry to
   the “navigation” timing buffer for BF cache navigation?

   - Nicolás: Can we add a new entry to the "navigation" entry-type

   - Would this break analytics scripts?  How often do they take the [0]th
   vs actually inspecting the last entry?

   - Ilya: Our gut feeling is that most analytics scripts probably take the
   [0]th entry, as the ergonomics are easier, so adding a new entry might be

   - Are different implementations today causing confusion? Anyone looking
   at the data?

   - Nic: We’re not doing anything with that right now
   - Ilya: ergonomics preferences for updating vs. a new entry?
   - Nic: Separate entry feels better as you don’t lose data
   - Ilya: A new entry will have zeroed out fields
   - Nic: which fields would be useful?
   - Yoav: What is Safari currently updating?

   - Resets all timings and updates navigation start to current time
   - Also, we want to keep the original time origin, right?

   - Philip: We definitely want to keep the original time origin
   - Alex: Anybody gathering this data and using it to measure/optimize the
   BF cache?
   - Yoav: might be the inverse - exclude BFCache entries
   - Nicolás: in which case, we can just not report anything
   - Philip: internal team interested in impact of BF cache on performance
   - Yoav: People could measure the impact of removing the unload event and
   compare history navigations with bf cache navigations.
   - Nic: Nobody has ever asked anything about that
   - Benjamin: More of a browser vendor measurement. Web developers can’t
   optimize for this
   - Yoav: They can avoid breaking BFCache
   - Ilya: Any other signal that the page came out of BFCache?
   - Philip: `pageshow` event with a persistent flag

   - Also `event.timestamp` could say when the browser started to take the
   entry from BFCache, enabling measuring the start of that event

   - Ilya: Sounds like a good way to implement that use case
   - Nicolás: Would require event.timestamp to be consistent across
   browsers. Currently it’s not specified that way
   - Ilya: So developers can verify that they don’t break BFCache using
   that. Measurement on top of it sounds like a curiosity.
   - Yoav: May want to measure benefits of unbreaking BFCache
   - Ilya: Already addressed use-case
   - Nicolás: Still need to align implementation behavior
   - Philip: Boris asked to count BFCache navigations with history
   navigations. Sounds like we shouldn’t
   - Yoav: yeah, they shouldn’t count for anything from a NavigationTiming
   - Nicolás: new entries will have inflated timestamps, as they’d refer to
   the original timeOrigin
   - Yoav: yeah, that’s WAI and developers can detect BF cache loads
   - Philip: Need to specify the pageshow event timestamp to be consistent,
   probably as part of HTML
   - Ilya: Summary:

   - There is a use-case for detecting BFCache navs, but it's met by
   listening for pageshow and knowing the timestamp from there.
   - There's not a lot of request to get more data from analytics vendors.
   - Request for Firefox/Safari to be consistent in not updating their
   entries on BFCache navs.
   - File issue on pageshow for event timestamp to be consistent

   - Can hitting enter on address bar to same URL be considered a
   navigation of type 'reload'?

   - Nicolás:

   - Bug reported on Chromium
   - Spec language is ambiguous when Enter is hit in the URL bar when a
   site is already loaded.  Is it 'reload' or 'navigation'?
   - Chrome treats this as a reload

   - Yoav: “reload operation” is not well defined.

   - UI actions are not well defined and different browsers can do
   different things as a response to them

   - Benjamin: This is a bit of a mess in Firefox, tbh. Clarification on
   this would be welcome

   - Part of the challenge is that there are many ways to initiate a reload
   from a user (click reload button, shift-click, URL bar + enter, function
   keys on Windows, etc) and they may all have slightly different behaviors

   - Nicolás: Many different things can happen in Chromium as well,
   depending on the specific user action and context
   - Yoav: NavigationTiming should use HTML’s reload-triggered-navigation
   behavior should fall out of that
   - Alex: Also have different behaviors, but clicking enter on the URL bar
   is clearly a new navigation, even if the URL hasn’t changed
   - Yoav: Maybe, but it’s an HTML discussion.
   - Ilya: So we should open a discussion on the HTML spec to discuss that
   gap. But I’ve observed users using that to reload, so it’s a judgement call
   that we need to make.
   - Benjamin: Would love to look into WebKit’s shift+reload and that
   behavior. This is an area that’s ripe for cleanup.
   - Yoav: Sure, let’s do the cleanup in HTML
   - Nicolás: and in the meantime, we continue with divergent behaviors?
   - Yoav: I’ll open an issue on HTML spec to better define what a reload
   nav for these cases

   - We'll then link directly to that clarification in HTML spec

   - Ilya: use cases

   - Reload button
   - URL bar + enter
   - {Ctrl,Cmd} + {R,F5}
   - Shift + {Ctrl,Cmd} + {R,F5}
   - Shift + reload button
   - Location.reload

   - Yoav: also no concept of force-reload in the HTML spec AFAIK
   - Benjamin: mobile also complicates this further

   - Two finger drag down is another “reload” gesture

Page Visibility

   - Lack of clarity on how occlusion behavior interacts with iframes

   - Yoav: meta question - who can own Page Visibility?

   - <crickets>

   - Yoav: the use-case for occlusion detection for iframes is covered by
   Intersection Observer v2. So seems like iframes should inherit visibility
   state from the parent
   - Nicolás: What does the current implementation do? Does it inherit?
   - Yoav: We definitely need tests for that
   - Nicolás: So adding a test is a reasonable first step?
   - Yoav: Yeah. IOv2 should be good enough for in-page occlusion. Exposing
   out-of-page occlusion is scary, and we shouldn’t
   - Benjamin: agree
   - Yoav: How can we test it in WPT? Manual tests?
   - Alex: WebDriver can maybe open a window and position it on top of
   - Yoav: Could work.
   - Yoav: AI to summarize discussion on the issue

On Wed, Dec 4, 2019 at 7:18 PM Yoav Weiss <> wrote:

> Hey folks!
> Your favourite WG is at it again! (and we have a call as well)
> On the agenda
> <>
> this week we have LCP updates. I'll be sure to add some issues to triage
> there as well in case there's time left.
> Please join us <>. As always, *the
> call will be recorded and posted online*.
> Cheers :)
> Yoav

Received on Monday, 9 December 2019 15:29:45 UTC