Re: WebPerfWG call - April 1st 2021 @ 10am PT

Hey folks,

The meeting's minutes
<https://w3c.github.io/web-performance/meetings/2021/2021-04-01/index.html>
and recording <https://youtu.be/c-tOFJAl81o> are now published.

Pasting the minutes here for convenience:

WebPerfWG call - April 1st 2021
Participants

   - Nic Jansma, Benjamin De Kosnik, Carine Bournez, CP Clermont, Michal
   Mocny, Nicolás Peña Moreno, Noam Helfman, Peter Perlepes, Steven Bougon,
   Yoav Weiss

Next Call

April 15th 2021 @ 10am PST / 1pm EST
Meeting Recording Survey

   - *Yoav*: Sent out a survey on usefulness or meeting recordings
   - … Appreciate if you can fill it out to help inform us
   -
   https://docs.google.com/forms/d/e/1FAIpQLSc1sk0e0Ddd--TZMzylh-GfMZQv5AQEoPR-mHzJMwqdUgowLA/viewform?usp=sf_link
   <https://www.google.com/url?q=https://docs.google.com/forms/d/e/1FAIpQLSc1sk0e0Ddd--TZMzylh-GfMZQv5AQEoPR-mHzJMwqdUgowLA/viewform?usp%3Dsf_link&sa=D&source=editors&ust=1618390134401000&usg=AOvVaw0mWsSahmMB7m3_nWSX7f6P>

TopicsPublishing - Yoav Weiss

   - *Yoav*: As part of Noam’s work on RT/Fetch, we need some changes in
   HRtime and others
   - … Publishing those changes was a bit of a manual process
   - … Had setup auto-publishing of HRTime in 2015, but the pipeline broke
   since then
   - … Seems we can refresh that decision
   - … First question I’d like to ask is if we can make that decision, or
   if there are objections
   - *Noam*: Can you clarify what auto-publish means?
   - *Yoav*: There’s a working draft (e.g. TR) published on the W3C site, a
   published working draft
   - … Whereas when we work on editor draft of specs, they are not
   automatically published unless we decide they should be
   - … Which means other specs cannot reference them without explicit links
   until we published those
   - … Auto-publish commits so when we land PR in HRTime, ResTiming, etc,
   so it goes to w3c.org/TR/[spec-name]
   - *Noam*: Makes sense
   - *Yoav*: Does it no longer apply to specs not in Working Draft?
   - *Carine*: We can do that for CRs as well
   - … Just for Transition Request we can’t do that
   - *Nic*: Are there any downsides to auto-publish?
   - *Carine*: Mostly a benefit to editors, no other downsides seen
   - *Yoav*: Decision made to auto-publish for WD and CR specs
   - … Other than that, I was looking at spec status spreadsheet
   - … HR-Time 3 is a working draft, and it’s fine to leave it there for now
   - … PerformanceTimeline L2 is a working draft. L2 was in PR and changes
   made brought it back to a WD as a result. Now we have 2 WDs in parallel.
   - … In my mind it makes sense to take L2 to CR->PR->REC
   - … Issues marked as L2 are currently closed, other than an issue asking
   that tests are clean
   - … Make sense to move PT L2 to CR?
   - *Nicolás*: Why was it moved back
   - *Yoav*: Added feature: supportedEntryTypes and buffered flag
   - *Nicolás*: Only see supportedEntryTypes
   - *Yoav*: Can do more archeology.
   - *Nicolás*: Makes sense to ask if people have objections to the
   additions to L2 and then move it to REC
   - *Yoav*: We removed buffered flag from L2 and put in L3 only.
   - … Added type as well
   - … Question for Carine: Do we need anything beyond working group
   decision to move PerfTimeline L2 to CR?
   - … And if that is sufficient, can we do that now?
   - *Carine*: We can do that now on the call, and get it in the minutes.
   We need to get a sense if there are objections.
   - … Would be more comfortable with a Call for Consensus by email, since
   it wasn’t on the meeting’s agenda
   - *Yoav*: I can take an AI for a CfC for moving PT L2 from WD to CR
   - *Carine*: Is there something in L3 we want to publish now?
   - *Yoav*: L3 has buffered flag, was there anything more?
   - *Nicolás*: I also added number of dropped entries. Nothing beyond that.
   - *Yoav*: Makes sense to publish L2 to REC and then move L3 to the
   living standard model.
   - *Carine*: If we are sending a CfC for L2, we could also ask to publish
   a FPWD of L3
   - *Yoav*: Auto-publishing is a tooling issue beyond the decision we
   recorded a few minutes ago
   - *Carine*: once we transition to FPWD
   - *Yoav*: Also AI to publish First Public Working Draft for L3
   - *Sean*: Quick addition: in L3 the disconnect method also clears the
   options list, which L2 didn’t have

ResourceTiming and NavigationTiming + Fetch

   - *Yoav*: Noam R. is doing a lot of work with integration Fetch into
   RT/LT, which was a barrier for us moving from L2 to L3
   - … Also if we can abandon the move L2 to REC for RT/LT and move to
   Living Standard now that we have Fetch integration behind us
   - *Benjamin*: Yes let’s not have a dual-track model
   - *Yoav*: Carine what would be the procedural bit here? CfC for moving
   them to Living Standard model?
   - *Carine*: The resolution would be to keep the two levels?
   - *Yoav*: Resolution would be to drop L3, stay on L2 forever-more, and
   move that to a CR-based Living Standard
   - *Yoav*: We need a CfC for call to CR for RT
   - … for NT since there’s significant work from Fetch integration, that
   may result in downgrading it to a WD, but once we have both of them in CR,
   do we need anything else for them to be a Living Standard?
   - *Carine*: It stays in CR forever basically, and something in the
   document says it’s a Living Standard
   - … RT L1 since it was never a REC do we drop it?
   - *Yoav*: I don’t think RT L1 has open issues.
   - *Carine*: I suppose why it’s still L1 is in CR it’s for testing
   - … It’s CR since 4 years ago
   - *Yoav*: I suspect it’s just because we haven’t done a good job making
   sure it’s not in CR for 4 years
   - … Looking at the current WPT tests for RT, we may need to analyze
   which tests are L1 related
   - *Carine*: If the group wants to say it’s a Living Standard, drop
   levels all-together in some way, that’s OK as well
   - *Yoav*: Don’t have strong opinions, have a slight preference for
   pushing L1 forward to REC, then make sure that’s documented.
   - … Apple never implemented L2, but they are not on this call. Any other
   strong preference? On L1 should we publish or abandon it?
   - *Sean*: I personally find having all sorts of Levels confusing
   - … When we implement stuff, we’re always referring to the latest one.
   So having L2 and L3 mixing in, why do we have both?
   - *Yoav*: The point is not to have both L2 and L3, but I think you’re
   saying that levels in general are confusing
   - ... I can formulate an email to the group about moving L2 to CR, as
   part of that also see if anyone has strong opinions about keeping L1 or if
   we can abandon it.
   - *Benjamin*: And then L3 will be Living Standard?
   - *Yoav*: We would abandon L3 (which didn’t have work), and move L2 to
   Living Standard
   - *Benjamin*: Sounds good
   - *Carine*: So that would essentially mean abandoning levels
   - *Nicolás*: Should we do that for PerformanceTimeline too?
   - *Carine*: That would mean changing the previous resolution to merge
   PerformanceTimeline L2/L3 and move to CR.
   - *Yoav*: Move L2 to CR, merge L3 to L2, and L2 will be Living Standard
   from now on
   - *Nicolás*: I think of it as renaming L3 to L2
   - *Yoav*: CfC is the same CfC, just the path is different. Instead of
   taking L2 to REC, merge L3 to L2 and make it Living Standard.
   - *Nicolás*: L3 is a superset of L2. No need to merge.
   - … Right now we have two branches, L2 and gh-pages.  Just renaming
   gh-pages to L2.
   - *Yoav*: You can look at it as merging, other than that we won’t be
   doing any merges
   - *Carine*: Looking at proactively where we can publish this
   - … I think we could reclaim the short name “performance-timeline”
   without the number at the end
   - *Yoav*: If we can reclaim that for L2 that would be ideal
   - *Carine*: L1 did not have “performance-timeline-1”.
    “Performance-timeline” points to L2.  We can remove “L2” from the title.
   Remove “-2” from URI.
   - … You can also find a “-4”, we may need to fix that

User-Timing

   - *Yoav*: We have published L1 and L2
   - … L3 is a Working Draft, would be worthwhile to push to CR, and make
   L3 the Living Standard
   - … Any objections?
   - *Sean*: Is my understanding correct that we call CR “Living Standard”
   - *Yoav*: We now have two versions of Living Standards.  One is that we
   push a spec to REC, then re-publish as REC for any future changes (but
   there is a process with that).
   - … The easier version is that we push to CR, say it’s a Living
   Standard, and future changes don’t require as much process.
   - … In a similar way where Fetch and HTML spec in the WHATWG.
   - … Requires some sort of group consensus
   - *Sean*: So if we do that for User Timing and we move L3 to CR, do we
   still need L1/L2 in REC status
   - *Yoav*: They will remain published, but we can generally ignore them
   as historical artifacts
   - *Carine*: We can claim they are superseded by higher levels.  We
   generally keep older revisions, where  there are cases where 1.0 is easy to
   implement in some cases, and 2.0 has additional features.  And people want
   to keep 1.0 where use-cases for earlier versions still exist. Which is not
   the case here.
   - … For this working group, I think we always want people to implement
   the highest level
   - … So we have to remove L3 from title, push to CR, declare it
   supersedes L2 and L1 when we enter Recommendation, and use Process 2020 to
   amend the REC
   - … Another possibility is to enter CR, and stay in CR forever.  That
   way we don’t supersede L1/L2 RECs, but we can obsolete them.
   - … And then once a year publish CR snapshots, which are CR required for
   approval
   - ... For the moment the forever-CR versus REC, it’s not clear which is
   best for each working group
   - … We need to go to CR for L3 which is just in WD.  We don’t need to
   decide that now.
   - *Yoav*: I think the group previously decided the forever-CR model is
   more favorable
   - … We can start by pushing WD to CR, revisit in future if needed.

Page-Visibility

   - *Yoav*: Currently in PR
   - … One HTML integration issue to resolve, then we could potentially
   take it to REC
   - … Probably need to do that first before we make the decision?
   - *Nic*: How much work would it be to resolve that issue?
   - *Yoav*: Issue 51
   - *Michal*: Finish line perhaps as little as as a day.  It’s
   well-outlined what it would take here.
   - ... Changes to this spec, HTML and dependencies, but not too bad
   - *Yoav*: Something you’d be able to push in near future?
   - *Michal*: I think so
   - *Yoav*: In order to move to REC, this is the last issue
   - *Michal*: I will take it
   - *Yoav*: Testing status we’re in perfect shape
   - *Nicolás*: PV testing isn’t the most complete
   - *Yoav*: I think it takes a lot of manual tests

Beacon API

   - *Yoav*: 0 open issues, currently in CR and we can take it to PR
   - … As far as tests go, we are almost green, two implementations for
   each of the tests
   - … Do we need a perfect score on tests to move to PR, or can we take to
   PR and fix tests on way to REC
   - *Carine*: It doesn’t have to be perfect, if we can justify and
   identify the issue then that’s OK
   - *Yoav*: We have 2+ implementations passing for each test
   - … To move that to PR, is that a CfC but a separate one?
   - *Carine*: I’d rather have a separate one
   - *Yoav*: AI to CfC

Possibility to get the HTTP status code from the Response Header ? · Issue
#126 · w3c/navigation-timing
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/126&sa=D&source=editors&ust=1618390134408000&usg=AOvVaw2-GjItxF7UrKVMzgYK0DJU>


*Yoav*: Feels like something we’d want to move to Resource Timing

*Nic*: I think there’s a similar issue there

*Nicolás*: You mentioned in the NavigationTiming issue that it would
require some opt-in?

*Yoav*: I think that it won’t for NT, but would for RT

*Nic*: RT#90 is a duplicate on the RT side

*Yoav*: Makes sense to fold this one into the other one
AppCache meaning #140
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/140&sa=D&source=editors&ust=1618390134409000&usg=AOvVaw0oCE-7croSyhRbAiOzpwIq>

*Nic*: Clarification question around what the time titled “AppCache”. What
components can contribute to that time in the diagram. Yoav, you commented
around it.

*Yoav*: AppCache is dead, let’s not bother with defining its delays too
much. Benjamin - what about Firefox?

*Benjamin*: deprecated

*Nic*: In the case of NT, it’s not the AppCache feature, but we were
referring to the browser cache in general. In the diagram we have AppCache
before DNS connection. It was meant to cover the browser cache - how long
it took to get the resource from disk cache. The name changed over time,
but it’s not about the AppCache feature.

*Yoav*: As far as implementations go, either we fetch the resource from
disk cache, or ignore the cache and go to the network. AFAIK, there are no
scenarios where we wait on disk, and only then go to the network. I’m not
sure that definition makes sense.

*Nicolás*: You’re saying that’s measuring when we try to see if it’s in
disk cache and fail do we then go to the network? I also don’t understand
what’s the delta between fetchStart and dnsStart.

*Nic*: We often see a non zero delta between those numbers and assumed it’s
disks spinning up

*Yoav*: I’d assume we won’t go to disk unless we know we find something
there

*Nicolás*: Worth investigating what’s happening there

*Nic*: In IE that time was accessing the cache index, which may not have
been in memory

… I can see if today we still see a difference there

… The basic question was “what is that time?” We can try to inform that
decision a little bit

*Yoav*: It would be interesting to do some research there.

*Nic*: Out of time, just wanted to point out great work on RT Fetch
integration.

On Wed, Mar 31, 2021 at 10:25 PM Nic Jansma <nic@nicj.net> wrote:

> Hi everyone!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> for our next call (Thursday April 1st @ 10am PT / 1pm ET) we will discuss:
>
>    - Auto-Publishing of specs
>    - Current status of specs and what's next
>    - Issue triage for navigation timing, resource-timing, others
>
> Plus any other issues you want to talk about. If you additional items,
> please add to the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> .
>
> Join us <https://meet.google.com/agz-fbji-spp>!
>
> The meeting will be recorded and published online afterwards.
>
> See you soon!
>
> - Nichttps://nicj.net/
> @NicJ
>
>