- From: Yoav Weiss <yoav@yoav.ws>
- Date: Mon, 3 Aug 2020 13:03:39 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CACj=BEioErw6EvAzkA2_D1YkyqznpE2UwmXkz7bcxWH+53QHTg@mail.gmail.com>
The minutes and video from last week's call are now available. Copying the minutes here for safe keeping: WebPerfWG call - July 30th 2020 Participants 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 people - ... 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 Friday - 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 <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/168&sa=D&ust=1596455851602000&usg=AOvVaw0WfvJAYa_-rynjutVAlvoN> - 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 <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/169&sa=D&ust=1596455851604000&usg=AOvVaw0BjRoi-jV2z0kQhrPnTW7G> - 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 frame. - ... 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 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/228&sa=D&ust=1596455851613000&usg=AOvVaw2uhMxz6iEa_zV3NhU1BOh1> - 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 <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/59&sa=D&ust=1596455851618000&usg=AOvVaw1RaTmoFgdd611vO4yLLoKQ> - 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 context* - 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 <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/63&sa=D&ust=1596455851624000&usg=AOvVaw2dyYpYGcqcMqR1oRlCX9mt> - 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 deprecating - 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 <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/65&sa=D&ust=1596455851628000&usg=AOvVaw1g6DfyhEv3lesbUWSO0jHV> - 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 Standard - 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 <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/51&sa=D&ust=1596455851632000&usg=AOvVaw1NgWVVXZS-1ni4tQ3M-wrk> is 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 - preload #144 - Request for dynamic preload like font url in CSS <https://www.google.com/url?q=https://github.com/w3c/preload/issues/144&sa=D&ust=1596455851634000&usg=AOvVaw0QSysYfhgXN8MkNtYozPZv> - 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 head. - ... 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 <https://www.google.com/url?q=https://github.com/w3c/preload/issues/148&sa=D&ust=1596455851640000&usg=AOvVaw0CNTkqHrdeomaKnhAOSAkf> - 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" https://github.com/w3c/performance-timeline/issues/169 <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/169&sa=D&ust=1596455851643000&usg=AOvVaw3o6c-xvgdc8LExP0Tj3TsG> - Yoav: Add a non-normative note to Resource Timing around TAO exposing URLs https://github.com/w3c/resource-timing/issues/228 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/228&sa=D&ust=1596455851644000&usg=AOvVaw3l0ds50wErCDv6GWKQWkPK> - Yoav: Respond to https://github.com/w3c/page-visibility/issues/63 <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/63&sa=D&ust=1596455851645000&usg=AOvVaw35-RQcJUYJHg4XufzmaTeE> - Philippe: Review https://github.com/w3c/page-visibility/issues/65 <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/65&sa=D&ust=1596455851646000&usg=AOvVaw2wfUVjh5UrRaiGzqu2fakX> - Yoav: Respond to https://github.com/w3c/preload/issues/144 <https://www.google.com/url?q=https://github.com/w3c/preload/issues/144&sa=D&ust=1596455851647000&usg=AOvVaw1NckjEkG2HNphLjEX_xNzh> - Yoav: Respond to https://github.com/w3c/preload/issues/148 <https://www.google.com/url?q=https://github.com/w3c/preload/issues/148&sa=D&ust=1596455851648000&usg=AOvVaw3Pge5MRLAgYGFG2Fd2sf4e> On Wed, Jul 29, 2020 at 9:37 AM Yoav Weiss <yoav@yoav.ws> wrote: > Hey all, > > After a short hiatus, we're back to talking web performance! > > The plan > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.jydyz2yv9bkc> > 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