- From: Yoav Weiss <yoav@yoav.ws>
- Date: Mon, 3 Aug 2020 13:18:09 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CACj=BEg_K70fKoxABVM=PUV-7RSet+bHsgkVxpRwoEoSSDMvNw@mail.gmail.com>
Actual links to minutes <https://docs.google.com/document/d/e/2PACX-1vQE0yblkBXaUueIEHhmtH36ccxDVmY48ivhPFNOV4m2k9mjbmRXsBWK5b39UM33ay5X8rSUw3IwuBXw/pub> and video <https://youtu.be/8rWMwc_x6FM>... On Mon, Aug 3, 2020 at 1:03 PM Yoav Weiss <yoav@yoav.ws> wrote: > 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:18:41 UTC