- From: Yoav Weiss <yoavweiss@google.com>
- Date: Mon, 12 Jul 2021 15:19:13 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAL5BFfXD46-RKAYbqZ1hGcr6oNvMP8nCcE8kJRbzn=Fpe19=Jg@mail.gmail.com>
Hey all! Minutes are now published <https://w3c.github.io/web-performance/meetings/2021/2021-06-24/>. Copying them here for convenience: WebPerfWG call - June 24th 2021 Participants Yoav Weiss, Nic Jansma, Alex Christensen, Benjamin de Kosnik, Carine Bournez, Giacomo Zecchini, Michelle Vu, Noam Helfman, Sean Feng Next Meeting July 8 2021 @ 10am PST / 1pm EST TPAC 2021 - Virtual! - *Nic*: TPAC will be virtual again this year. - … October 18th through 29th - .. Breakout 18th till 22nd - … the rest is group meetings - … Like last year, we can build an agenda ahead of time - *NoamH*: What TZ? - *Yoav*: we had set late afternoon Europe, early morning Pacific - *Nic*: We did 12pm-3pm EST, 4 days in a row - *Yoav*: Carine, are there mandatory times, or can we schedule on our own? - *Carine*: The second week is meant for joint group meetings. Some groups prefer to schedule their own meetings outside of TPAC, and reserve the second week for joint meetings, to reduce conflicts - *Yoav*: Do we have any strong preference for week and timezones? - *NoamH*: For me it’s becoming late, but I can always participate in the earlier sessions - *Yoav*: We can always schedule sessions your participate in earlier - *Benjamin*: West coast could start earlier, 8am PST? Palatable for me, may help Europe - *Nic*: last year we did 3-hrs days, on 4 days, we could do that again. - *Benjamin*: I’ve seen other groups split it out a bit more over multiple days. If we have two weeks we could do M,W,F over two weeks even - *Yoav*: Are you suggesting 2x 3hr sessions in one week, and 2x 3hr sessions in the next? - *Benjamin*: 2hr meetings on M,W,F and work sessions on Tu,Thr - *Yoav*: We can create a poll with multiple options for layouts, and take it from there Preload & Resource Hints => CR snapshot (??) - *Yoav*: Moved these to WHATWG, captured in our charter - … One suggestion from a member was to try to get them to CR snapshot before moving them over, mostly for IPR purposes - … Looking into what that would entail and talking to Carine and other folks, it seems that would require a bunch of work to do that - … Personally, this is not work that I can take on, and I’m not aware of anyone else that can take on that work - … Question to the group: is someone interested in taking on work to take Preload/Resource Hints to CR as part of working group, and only then move them to WHATWG? Otherwise we can skip that phase and attempt to move them directly. - … Asking for volunteers - *Alex*: I have no idea what it entails but I need to make sure that succeeds. I can volunteer and ask for guidance along the way. - *Yoav*: Carine, maybe we can start an email thread with Alex, outlining the details? TAG review and wide review and create all of the documents that it entails. - *Yoav*: AI for Carine to start an email thread for Alex and myself and we can start this IssuesrIC #92: Editorial: rename spec to requestIdleCallback() <https://www.google.com/url?q=https://github.com/w3c/requestidlecallback/pull/92&sa=D&source=editors&ust=1626098802683000&usg=AOvVaw16UqBK-sWZQoCtxBlmArLm> - *Yoav*: Suggestion from Marcos is to just call the spec requestIdleCallback, currently called “Cooperative Scheduling of Background Tasks”. - … I’d suggest we rename to make it easier - *Noam*: Sounds like a good idea - *Carine*: Can we get a status update on this doc, it’s in a PR for quite some time. Should it go back to CR again? - *Yoav*: It’s in PR, there are 4 open issues IIRC that need some work. We were having some discussions a year ago, but that died out - … Bringing it back to CR and figuring out a way to re-work on those issues makes sense, and once those are resolved bring it back to PR and maybe REC - … Unlike other specs this one seems like it could be done once we resolve the issues - … Makes sense to bring it to REC other than living standards CR - *Carine*: Agreed - *Yoav*: Any objections? - (none) - *Carine*: Do we have the editors around? - *Yoav*: Ross is not an active editor, I’m in the process of trying to find an active editor on the Chrome side but it may take a while. I can put myself as an Editor if needed, but I don’t have the bandwidth to deal with the issues in the near term. - *Carine*: We may need to go to TAG and wide review so I want Editors to be aware of that - *Yoav*: Was it that our previous review was long ago and needs to be redone? - *Carine*: Exactly, I think we may hit that with all of our specs - *Yoav*: Right now we don’t have an active editor, but I hope to find one within a few months - … Willing to put my name as a temporary Editor, and move Ross and Ilya into former editors in the interim until a new Editor is found - *Carine*: Moving from PR to CR we need a wide review - … There have been substantial changes from last time, the comment which prevented it from going from PR to REC. It wasn’t formal, but it should have gone back to CR. - … Apart from Page Visibility, the other ones will require a review - *Yoav*: Can we leave the spec as-is at PR until we find someone with bandwidth to tackle that kind of a wide review - *Carine*: Yes - *Yoav*: We’ll revisit once we have an active editor, move to CR and fix issues, then go to wide review - *Carine*: The original issue that prevented REC was fixed, around idle time, but there were substantive changes for review - *Yoav*: Issue 71 was stuck on review, 82, 86, 87 are ones that we need to deal with - … There are substantial issues to still discuss - … In order to move spec towards REC - … All of these changes are meaningful. Not sure which of them happened since Wide Review. - … Going back to CR and then towards REC sounds like the right path, but for all of that we’ll need an active editor JS profiling and COI restrictions - Noam Helfman - *Noam*: We’ve done some work recently, works from Microsoft/Google/Chromium/Facebook - … We came to conclusion that it’s OK to remove the restriction for cross-origin isolation - … It was done in collaboration with WebAppSec WG - … Was a security review and everyone was OK with it - … Now we’re removing that from the spec and help followup implementations from the vendors that support it - *Yoav*: Great in terms of adoption for this - … Will make API significantly more applicable in a safe way - … In terms of implementation, I don’t think Chromium has actually lifted the restriction - *Noam*: Andrew has issued a PR for that, it’s close - *Yoav*: One place where this could have implications on other work is we talked about potentially reusing some of the infrastructure there for LongTask attribution, but it didn’t seem very feasible with the COI restriction in place, as it would mean LongTask attribution would only work in COI - … But maybe now that could change things on that front - *Noam*: One is LongTask attribution. With LT API we already have timestamps we could link to profiling. Same goes for EventTiming spec, which would benefit from attribution aspects, but it’s not necessary as you could link to the right stacks at the time. - *Yoav*: Users that are listening to LT APIs and want attribution, could turn on Profiling and correlating timestamps to get attribution for free. - *Noam*: If part of the spec and you’re tracking LongTasks or EventTiming or ElementTiming, but then it’d be even easier to adopt and as a tool to troubleshoot real problems for the users - *Yoav*: Linked to the Chromium CL <https://www.google.com/url?q=https://chromium-review.googlesource.com/c/chromium/src/%2B/2967756&sa=D&source=editors&ust=1626098802687000&usg=AOvVaw3HBfqKNs3ng0QjuAFNDz54> - *support from Akamai and Salesforce* Can non-W3C members join TPAC? - Yes, get in touch with WG chairs Fetch #1232 (RT): Add a "revalidated" cache state <https://www.google.com/url?q=https://github.com/whatwg/fetch/pull/1232&sa=D&source=editors&ust=1626098802688000&usg=AOvVaw1XIH71898p50yjDu4bo_xD> & RT #272: Add a revalidation cache state and adapt transferSize to it <https://www.google.com/url?q=https://github.com/w3c/resource-timing/pull/272&sa=D&source=editors&ust=1626098802689000&usg=AOvVaw1e9VfgqrRQENvGsUEkEkKI> - *Yoav*: A while ago we decide that transferSize can be limited to encodedBodySize + fixed size for headers in order to support current use cases and not leak what size of headers is actually - … While implementing it, I realized what we specified wasn’t sufficient for implementing both use-cases - … For revalidated cached responses, we want to just provide the fixed header size without the encodedBodySize to enable folks to distinguish between responses coming from the cache, the network as well as network-revalidation. - … That bit of state was missing, I PR’d a change to add that state to Fetch - … That’s what I wanted to discuss but we’ve done that a while ago, just wanted to let people be aware of this - … Was interested if other implementations (mainly Mozilla, as they have implemented transferSize) have an issue on record to follow that behavior change? - *Benjamin*: There’s an issue filed, and we’ll be working on Fetch integration in H2 so this is relevant - *Alex*: Can you file an issue for Webkit also? I’ve implemented it as off-by-default to see what tests pass if it were to be implemented. - *Yoav*: AI to file an issue <https://www.google.com/url?q=https://bugs.webkit.org/show_bug.cgi?id%3D227393&sa=D&source=editors&ust=1626098802689000&usg=AOvVaw2cx0vA_meIx00BcXyjmb8A> NT #146: A scenario where transferSize is 0 for non cached loads (or may be not) <https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/146&sa=D&source=editors&ust=1626098802690000&usg=AOvVaw0xEJkzsOKRn-Owi3FShW1O> - *Yoav*: It seems like a scenario where this is a Chromium bug report more than anything. - … When the resource is in the process of navigating and gets interrupted, the transferSize is 0 but should not be the case - … Assuming the resource was fully downloaded over the network, transferSize is actual body size plus constant - ... Move the issue to an implementation bug - *Nic*: I don’t think there’s anything here the spec is unclear about - *Yoav*: Move to Chromium bug <https://docs.google.com/> On Wed, Jun 23, 2021 at 10:19 PM Yoav Weiss <yoavweiss@google.com> wrote: > Hey folks, > > Let's meet up <https://meet.google.com/agz-fbji-spp> to talk webperf! The > agenda > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.gkilfdieaqp> > for tomorrow is somewhat light. > We have a few administrative things to discuss: virtual TPAC (again), > whether or not we want to transition Preload and Resource Hints to CR > before moving their processing models to the WHATWG, as well as a potential > renaming <https://github.com/w3c/requestidlecallback/pull/92> of the > "Cooperative Scheduling of Background Tasks" spec to requestIdleCallback, > as everyone already call it. > Otherwise, we have a few issues to triage, but if you have any agenda > items you wanted to discuss and were too shy to ask, now's the time! :) > > Unless there are objections, the call will be recorded and posted online. > > See y'all tomorrow! :) > Yoav >
Received on Monday, 12 July 2021 13:20:00 UTC