Re: WebPerfWG call - July 30th 2020 @ 10am PST

The minutes and video from last week's call are now available. Copying the
minutes here for safe keeping:
WebPerfWG call - July 30th 2020

Yoav Weiss, Nic Jansma, Sean Feng, Andrew Galloni, Noam Helfman, Philippe
Le Hegaret, Subrata Ashe, Michal Mocny, Benjamin De Kosnik, Annie Sullivan,
Steven Bougon, Nicolás Peña, Peter Perlepes,

Next Meeting

August 13 at 10am PST / 1pm EST

MinutesTPAC Meetings

   - Yoav: Week of October 19th got the most votes for everyone to be able
   to join
   - ... Also discussed having a couple half-day hack-a-thons, tentatively
   scheduled in September
   - ... Will send out some proposals to the mailing list for those dates
   - Nicolás: What would be the timing for TPAC hours?
   - Yoav: We were thinking 4 days worth of 3-hour slots
   - ... This time of day (10am PST / 1pm EST) would be most compatible for
   - ... We're thinking an hour before and an hour after this slot (9am PST
   - 12pm PST)
   - ... 3-hour slots with a break in the middle of each
   - Philippe: Are you thinking Mon-Thurs or Tues-Fri?
   - Yoav: Let's aim for Mon-Thurs so we're not keeping people late on
   - Nic: Can we send out some calendar invites to lock down those times
   for people?
   - Yoav: Yes, I can take an action item for that

IssuesPerformance Timeline

   - performance-timeline #168 - Reset the observers

   - Michal: Feature request for resetting metrics during SPAs / etc
   - ... Part of larger SPA story around having "Next" LCP and such
   - ... Will try to find the best "umbrella" bug and assign this as a dupe

   - performance-timeline #169 - Determining if the buffer was full when
   using the buffered flag

   - Nic: This came from a discussion last month around determining if a
   buffer was full
   - ... This is something we've seen in the wild in the past with
   ResourceTiming, especially when the buffer was smaller at 150 entries per
   - ... No strong opinion on how this is exposed (3 options were presented
   via Nicolás)
   - Nicolás: Any other concerns with exposing this? We’re trying to find
   the right shape to expose it.
   - Nic: We also have some "prior art" here with the ResourceTiming
   onResourceTimingBufferFull event
   - Yoav: Though that isn't as useful, as you'd need to have JS running on
   the page prior to the event in order to consume it.
   - ... Having a third parameter to the Observer callback seems like a
   good backwards-compat way to expose it
   - Nicolás: The list could contain multiple entry types, so we'd also
   need to provide a list of buffers that were full. Won’t be as nice.
   Maybe having that complex object be part of the list interface would be
   better than a complex callback parameter
   - Yoav: Or we could compress it to a single "one of these buffers was
   full" flag
   - Nic: In our consumption, we generally observe one type of buffer at a
   time (e.g. only RT).  One edge case would be for Paint Timing and LCP.
   - Nicolás: For paint timing, the buffer would always be full, as it’s
   the size of 1.
   - Noam: Could we offer an API that provides the buffer sizes by type?
   - Yoav: Maybe a separate API that gives you the static buffer sizes...
   - ... Actually, what you care about isn't what the buffer size is, but
   whether entries were dropped at all, right?
   - Nic: Correct
   - Yoav: So we could provide a signal for any dropped entry. And that
   would also work for the PaintTiming case using a single boolean.
   - … That signal can then help you know you need to register your
   observers earlier, complain to browsers to increase buffer sizes or both.
   - Nicolás: I can submit a PR with the proposed change and tag folks.

Resource Timing

   - resource-timing #228 - Timing-Allow-Origin may expose allowed URLs

   - Yoav: TAO allows either a wildcard or list of URLs, but doesn't
   require CORS, along with Origin header.  As a result, without Origin
   header, you may want to send TAO but don't know which host to send it for
   - ... This scenario could result in a resource owner writing a list of
   all possible embedders, which could expose those (not in a web context, but
   to e.g. crawlers)
   - ... This isn't something I've personally seen in the wild
   - ... Noam then argues that we should move TAO to a model closer to
   CORP, rather than CORS. It’s a complex question that would require some
   cross-WG thinking with WebAppSec folks
   - Nicolás: We could add a non-normative note in the spec saying that the
   TAO header could expose this information
   - Yoav: Not a ton of people are using Referrer Policy to omit referrer
   altogether, so dunno how of an issue that would be to real deployments. We
   can add a note saying “If you don't have an Origin nor Referrer, then don't
   send TAO unless it's `*`”.
   - Nicolás: Otherwise we need other security people to weigh in on this
   - Yoav: Broader issue if we want to align closer with CORP or CORS is
   being discussed.  We need to figure out a way all of these opt-ins work
   together and play nicely together.
   - ... Good topic for focused TPAC discussion
   - ... Adding a note makes sense to me

Page Visibility

   - page-visibility #59 - The spec's definition of hidden is unclear and
   should be updated to better account for mobile use cases

   - Yoav: Previously discussed, but there are some open questions here
   - Nicolás: May be hard to WPT test this, but we should agree on the
   design first
   - Benjamin: At this point I'm not sure tab switchers have a top-level
   browsing context
   - Yoav: I'm not 100% sure they're implemented that way
   - Benjamin: One of the questions in this issue is if we have a page
   visible and we take a snapshot of it and we put it on one of these tab
   trays, is it "visible"?
   - Nicolás: I would say it's not visible, since the snapshot was taken
   when it was last visible
   - Yoav: Agree that a snapshot is not "active", and that's what Philip is
   suggesting here
   - ... While they are theoretically visible since they are snapshots the
   user may see, they are not active or interactive unless the user moves them
   to the foreground
   - ... I don't think they should be different than backgrounded tabs,
   backgrounded and hidden
   - Nicolás: Firefox’ behavior seems like the right one. We should file
   bugs against UAs that aren't doing the correct behavior.
   - Benjamin: *asks for clarifications regarding the top-level browsing
   - Nicolás: When the browser moved to the tab switcher, you haven’t
   closed the actual tabs, they are just backgrounded. The tab switcher is not
   a web page.
   - Yoav: This issue is about adding a language that defines these
   browsing contexts and their state.
   - Benjamin to review the issue and comment on the bug

   - page-visibility #63 - Treating .hidden as "historical" seems unhelpful

   - Yoav: There is no reasonable path for us to deprecate and remove the
   ".hidden" attribute
   - ... I don't have context on when this "historical" flag was added.
   Not sure what our policy is for when we can mark interfaces as such.
   - Philippe: We have a historical section in the NavigationTiming
   section. Moved to the appendix and pretend they don't exist anymore.
   - Nicolás: Past performance people wanted to deprecate "hidden" since
   there were 3 visibility states (visible, hidden, prerender), but now there
   are only two again (visible, hidden). So no clear what’s the benefit of
   - Yoav: Would be good to have only one way to query that data. But also,
   unclear we can actually deprecate. Not sure if we have use-counters for
   ".hidden", but I assume they would be high.
   - ... Do we have a general W3C policy on when to mark things historical
   - Philippe: Nothing I know of
   - Yoav: To review

   - page-visibility #65 - Republish spec

   - Nicolás: There are open issues that may be blocking
   - Yoav: My understanding is that they are not blocking publishing
   - Philippe: We need to go back to CR and solve the issues in parallel
   - Nicolás: I would like to add new visibility state
   - Yoav: Test-wise, this is good to go to REC.  If we were to add new
   features right now, that might delay moving forward.
   - ... Ideally, I’d love to publish L2 as a REC and move L3 to a Living
   - Philippe: I could re-publish what we have right now, where we have a
   L2 branch.  Main branch moves to L3.
   - Nicolás: Seems reasonable as long as the extra L2 changes we want
   won't be too big
   - Michal: One if these is trivial. #51
   more substantial, but the issue is present in L1 already.
   - Yoav: It’s a spec health issue. We can put this work in main (L3)
   branch and can decide if we want to backport to L2
   - Philippe: To publish


   - preload #144 - Request for dynamic preload like font url in CSS

   - Yoav: Asking for a group of preloaded resources so they can define
   multiple ones for fonts. e.g. if you support WOFF2 then preload one
   resource otherwise preload another.  Similar to <picture> element.
   - ... We've talked about this in the past as a way to preload responsive
   images.  We concluded it won't work as we can't add new elements to the
   - ... Suggestion here is to re-use the <link> element, but the issue is
   that the <link> element is self-closing.  Would require a complex change to
   HTML spec.
   - Philippe: Wouldn't this affect font-matching algorithms?
   - Yoav: Assumption here is the developer knows the font will be used,
   and enable the browser to discover them ASAP
   - Nicolás: Is the concern in this scenario all 3 fonts would be loaded?
   - Yoav: Yeah.
   - Philippe: I would suggest we work with the CSS working group on this
   - Noam: This proposal could also be used for audio, video, fonts
   - Yoav: Basically this is a multiple-choice option for Preload
   - ... We talked about this problem in the past and concluded it doesn't
   have a strong enough use-case to justify the complexity (that was the
   conclusion for <picture>).
   - ... There are no modern browsers today that support Preload and don't
   support WOFF2.
   - ... An interesting angle to solve this problem but not feasible due to
   <link> elements being self-closing
   - Nicolás: To clarify, is this already solved for images?
   - Yoav: For images this is partially solved for srcset with the
   `imageset` and `imagesizes` attributes for preload that enable you to
   specify multiple resources and browser picks them in similar way for srcset.
   - ... Doesn't work for a <picture> element that has different art
   direction & crops for different viewports -- this isn't something you can
   preload today.
   - ... I don't think we can re-use that solution for this
   - ... I'll respond to that issue

   - preload #148 - Link header processing

   - Yoav: Processing for <link> headers isn't really defined anywhere
   other than vaguely in HTML.
   - ... Should <link> header processing for preload be defined in Preload
   spec or somewhere else?
   - ... From my perspective this feels more like something that should
   belong in HTML.
   - ... Does that make sense this should belong in HTML and not Preload
   spec specific?
   - Nicolás: Yes, makes sense

Action Items

   - Yoav: Send out calendar invites for TPAC meetings
   - Nicolás: Submit a PR for performance-timeline to add a "was an entry
   dropped from this buffer"
   - Yoav: Add a non-normative note to Resource Timing around TAO exposing
   - Yoav: Respond to
   - Philippe: Review
   - Yoav: Respond to
   - Yoav: Respond to

On Wed, Jul 29, 2020 at 9:37 AM Yoav Weiss <> wrote:

> Hey all,
> After a short hiatus, we're back to talking web performance!
> The plan
> <>
> for this week's call is to triage and discuss recently opened issues, as
> well as talk about TPAC logistics for the upcoming virtual meetings.
> As always, the call will be recorded and posted online.
> Cheers :)
> Yoav

Received on Monday, 3 August 2020 11:04:12 UTC