Re: WebPerfWG call - Thursday June 24th @ 10am PST

Hey all!

Minutes are now published

Copying them here for convenience:

WebPerfWG call - June 24th 2021

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
   - *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()

   - *Yoav*: Suggestion from Marcos is to just call the spec
   requestIdleCallback, currently called “Cooperative Scheduling of Background
   - … 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
   - *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
   - … 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
   - *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
   - *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
 & RT #272: Add a revalidation cache state and adapt transferSize to it

   - *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
   - … That bit of state was missing, I PR’d a change to add that state to
   - … 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

NT #146: A scenario where transferSize is 0 for non cached loads (or may be

   - *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


On Wed, Jun 23, 2021 at 10:19 PM Yoav Weiss <> wrote:

> Hey folks,
> Let's meet up <> to talk webperf! The
> agenda
> <>
> 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 <> 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