Participants

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: https://doodle.com/poll/m78puh6nrk2cp546

PING

• Ping Privacy Request Reviews:

• Resource Timing: https://lists.w3.org/Archives/Public/public-privacy/2019OctDec/0056.html
• Performance Timeline: https://lists.w3.org/Archives/Public/public-privacy/2019OctDec/0057.html

Largest Contentful Paint

Annie Sullivan

• https://github.com/anniesullie/LCP_Examples
• Why are body background images invalidated as candidates for LCP?

• https://github.com/anniesullie/LCP_Examples/blob/master/body_background/README.md
• 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

• https://datastudio.google.com/reporting/1sCHMXg3hgza3vqNVhDFAftYRgI94s2da/page/QDj4
• 
• 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)

• https://datastudio.google.com/reporting/1sCHMXg3hgza3vqNVhDFAftYRgI94s2da/page/aWq4
• 

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

Issue Triage

Navigation 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 timeline?

• 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 safe?

• 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 perspective
• 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 and 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 another?
• Yoav: Could work.
• Yoav: AI to summarize discussion on the issue