- From: Yoav Weiss <yoav@yoav.ws>
- Date: Mon, 9 Dec 2019 16:29:22 +0100
- To: public-web-perf <public-web-perf@w3.org>
- Cc: Ilya Grigorik <igrigorik@google.com>, Philippe Le Hegaret <plh@w3.org>, Annie Sullivan <sullivan@google.com>
- Message-ID: <CACj=BEh_K4QkUi5nW9M99hhUiEowhQrWHUEh3EZjaKXLbvjVfw@mail.gmail.com>
Thanks all for joining the call last week.
A recording <https://www.youtube.com/watch?v=slW6OxYKp8M&feature=youtu.be>
of the call as well as the minutes
<https://docs.google.com/document/d/e/2PACX-1vQRmNQiYCtmBGHPNyRhWKOW0h6bkI-wL-nMylO1-yqBlKDDrEqPRs5BPNHRGZfWLJYXrGyF0i4GUqbd/pub>
are now available. Posting the minutes here for safe keeping:
WebPerfWG call - December 6th 2019
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
<https://www.google.com/url?q=https://doodle.com/poll/m78puh6nrk2cp546&sa=D&ust=1575908628975000>
PING
- Ping Privacy Request Reviews:
- Resource Timing:
https://lists.w3.org/Archives/Public/public-privacy/2019OctDec/0056.html
<https://www.google.com/url?q=https://lists.w3.org/Archives/Public/public-privacy/2019OctDec/0056.html&sa=D&ust=1575908628976000>
- Performance Timeline:
https://lists.w3.org/Archives/Public/public-privacy/2019OctDec/0057.html
<https://www.google.com/url?q=https://lists.w3.org/Archives/Public/public-privacy/2019OctDec/0057.html&sa=D&ust=1575908628976000>
Largest Contentful Paint
Annie Sullivan
- https://github.com/anniesullie/LCP_Examples
<https://www.google.com/url?q=https://github.com/anniesullie/LCP_Examples&sa=D&ust=1575908628977000>
- Why are body background images invalidated as candidates for LCP?
-
https://github.com/anniesullie/LCP_Examples/blob/master/body_background/README.md
<https://www.google.com/url?q=https://github.com/anniesullie/LCP_Examples/blob/master/body_background/README.md&sa=D&ust=1575908628977000>
- 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
<https://www.google.com/url?q=https://datastudio.google.com/reporting/1sCHMXg3hgza3vqNVhDFAftYRgI94s2da/page/QDj4&sa=D&ust=1575908628978000>
-
- 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
<https://www.google.com/url?q=https://datastudio.google.com/reporting/1sCHMXg3hgza3vqNVhDFAftYRgI94s2da/page/aWq4&sa=D&ust=1575908628978000>
-
- 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 TriageNavigation Timing
- Add a new entry type for navigations from the BFCache
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/118&sa=D&ust=1575908628979000>
- 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'?
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/116&sa=D&ust=1575908628984000>
- 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
<https://www.google.com/url?q=https://html.spec.whatwg.org/%23the-location-interface:reload-triggered-navigation-2&sa=D&ust=1575908628986000>
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
<https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/56&sa=D&ust=1575908628990000>
- 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
On Wed, Dec 4, 2019 at 7:18 PM Yoav Weiss <yoav@yoav.ws> wrote:
> Hey folks!
>
> Your favourite WG is at it again! (and we have a call as well)
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.pdptt3pnkl1w>
> 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 <https://meet.google.com/agz-fbji-spp>. As always, *the
> call will be recorded and posted online*.
>
> Cheers :)
> Yoav
>
Received on Monday, 9 December 2019 15:29:45 UTC