W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2021

Re: WebPerfWG call - April 15th 2021 @ 10am PT

From: Nic Jansma <nic@nicj.net>
Date: Mon, 26 Apr 2021 23:58:40 -0400
To: public-web-perf <public-web-perf@w3.org>
Message-ID: <4479629f-4be2-9a03-79e4-1d341785b1e5@nicj.net>
Minutes 
<https://docs.google.com/document/d/e/2PACX-1vRvYDICU_ExSUqeFIrDJMtYVwTtDl97hNt7ZTm84rwNLbqDnMQ16Nh5vb2PKXtsc611RRzFoFROo_ja/pub> 
and recording <https://youtu.be/eK5Y9kOPh9Q> are now available, and 
published 
<https://github.com/w3c/web-performance/tree/gh-pages/meetings> to Github.


    Participants

Giacomo Zecchini, Nicolas Pena Moreno, Noam Rosenthal, Andrew Galloni, 
Nic Jansma, Patrick Hamann, Yoav Weiss, Steven Bougon,


    Minutes


      Meeting recordings

  * Nic: We’ve heard concerns around meeting recordings
  * … We sent out a survey RE the value/friction they add
  * … Wanted to discuss the group’s thoughts and seek alternatives
  * … The chairs see value in the recordings, think it’s increases
    transparency outside the groups, can be used to share or go back in
    time and review
  * ... Also helps with scribing and fixing up the minutes and ensure
    people’s opinions are accurately scribed
  *
  * … Surprised by how many people watch the recordings
  *
  * … Other takeaways: 5/25 watched prior meeting recordings before
    joining the group
  * … 8/25 said recordings add friction, so would be good to hear more
  * … No one said that they can’t join
  * … 20/25 thought it’s increasing transparency
  * … 2/25 thought recordings risk turning the meeting into a “performance”
  * … So I think we saw a mix of positive and negatives
  * … We explored alternatives:

  * Chair only recordings for scribing
  * Record only presentations, but not followup questions
  * Hire a professional transcriber

  * … Wanted to see if anyone wanted to talk about this
  * Steven: So people contacted you saying that they can’t join, but
    then didn’t answer?
  * Nic: Or they weren’t aware of the survey. May also be related to
    legal requirements
  * … We don’t have to come up with an answer, just want to make sure
    anyone can participate
  * … How good/bad it would be if we won’t record at all?
  * Steven: I see a clear benefit in recording. One of the browser
    vendors had a different recollection of what was said, and having a
    recording clears those misunderstandings
  * … We can go back and see what was said
  * Nic: Transcriptions are somehow helpful but are not perfect, so
    easier to go to the source
  * Noam: Would be good to hear from someone who opposes recording
  * Nic: Either that, or someone that answered it adds friction
  * Steven: Support an official transcriber. Tried a transcription service
  * … Can help people searching for our discussion, reduce load from
    chairs, and avoid conflicts in mis-transcribing
  * Nic: That’s one of the things that going back to the video helps
  * … We have all the transcripts available in a GH repo
  * Nicolas: Quick question. If we have members that legal requirements
    prevents them from recording, what do we do
  * Yoav: The process forces us not to record in such a case
  * Nic: Let’s not dwell on it. Please share concerns with us
  * … For now we can only record if no objections


    Next Meeting: 4/29 @ 10am PST


    Spec editors community group

  * Nic: Anybody that works on specs may want to join
  * https://www.w3.org/community/speced-cg/
    <https://www.google.com/url?q=https://www.w3.org/community/speced-cg/&sa=D&source=editors&ust=1619499229865000&usg=AOvVaw2Tp3GjhiVFzpDfkneVBJYl>


    Noam Rosenthal - on RT Fetch integration

  * Noam: Wanted to present the work we did in the last few weeks
  * … Wanted to solve a long standing technical debt with RT and NT
    defining the processing model separately from HTML and Fetch
  * … The processing model was saying the same things in different
    terms, and saying when things are supposed to be measured
  * … The idea of this work was to change that and instead of putting
    everything in those APIs, the entries would be marked as they happen
    in the relevant standards
  * ... And the RT/NT specs would just define how they are exposed
  * ... A lot of it is already in the editor’s draft
  * … Resource Timing had a very elaborate processing model that was
    talking about how each metric is measured. This is changed and now
    the different metrics are just a timestamp conversion from something
    called timingInfo that arrives from Fetch.
  * … Easy to follow the reference to Fetch that know when it’s measured
  * … Can go to the reference and see e.g. when is redirectEndTime measured
  * … This mirrors how the browser implementations work, where there’s a
    struct that’s later exposed by the API
  * … The same goes for Navigation Timing, e.g. previous document unload
    timing, the spec had to define what’s the previous document
  * … Now we just point to the HTML spec that defines when that timing
    is set
  * … Also interesting because it’s uncovering issues
  * … One of those issues is workerTiming. An explicit issue to change
    that is in review
  * … A new issue that was uncovered is what happens with network errors
    - should they get surfaced in Resource Timing
  * Npm: Do we know what browsers currently do for CORS network errors?
  * Noam: For CORS yes, for other errors not necessarily, which can
    expose CORS network errors
  * Npm: Cases for having network errors
  * Nic: We do for RUM and have a few open issues on capturing instances
    of non-200 errors
  * … At this point most browsers report most error cases in resource timing
  * Npm: This is about network errors, not HTTP errors. We agreed we
    want to report HTTP errors. Is there a use case to report CORS
    errors or other network errors?
  * … Easiest to not report them at all
  * … Are people using them to get visibility?
  * Nic: Overlap with reporting API and NEL
  * Noam: Another solution is to report only with TAO enabled, so we
    report timing of when called Fetch vs network error
  * … This is a discussion that evolved from this, would be good to
    continue on the GH issue
  * … So far this spans 7 different repos, so hard to say where the meta
    bug should be
  * … Quite a few things that are done and others in review
  *
  * … Fetch itself does not report RT and it’s up to the caller to say
    what’s their initiator type and when to mark the entry
  * … Mimics the implementation, where callers sometimes do this before
    or after the load event
  * … There needs to be work on the HTML spec and Beacon, saying at this
    point report the resource
  * … Still pending work
  * … Several issues fleshed out are already fixed
  * … E.g. TAO protection for nextHopProtocol and other privacy/security
    issues
  * Yoav: Amazing work!
  * Noam: Let’s try to keep the specs clean from now on and not
    accumulate more technical debt
  * … Now transferSize becomes a “fake” measurement (to avoid leaking
    header size)
  * … Questions?
  * Yoav: Implementations alignment? Benjamin, have ya’ll reviewed?
  * Benjamin: Excited about this work. The right standard for these
    things is in HTML and Fetch, so this is all great. Full support
  * … Last week you asked about AppCache
  * … As part of Fetch integration I would like to have some of the bits
    like AppCache to be clarified
  * … When do you expect SW to land?
  * Noam: In the next week, PRs are up
  * Benjamin: Have some RT WPT fails.  Waiting for this to solidify.
    Planning to review in a few weeks.
  * … Really like TimingInfo
  * Npm: Any changes beyond the TAO failed that we need to be aware of?
  * Noam: Capping of transferSize - encoded size + 300
  * … Otherwise, the SW stuff follows implementations
  * … One thing that may be a bigger change once the HTML specific bits
    are in place
  * … The previous spec didn’t specify when entries are reported.
    Currently the only caller that’s fully specified is fetch() and
    there it’s documented exactly when the entry is reported.
  * … It would be the same for the HTML based callers, which will be a
    change
  * … One other thing that popped up from this is the question about
    media and resource timing - what happens with resources that never end
  * … Should they be reported? When? Especially since responseEnd is the
    most intricate part of measuring
  * … Another thing a little strange in spec, response is not really defined
  * … response is this opaque thing that does all kinds of associated things
  * … RE implementations - these are all the different things for now
  * Npm: I wonder if we should do a hackathon for the WG to add all
    those tests. Would people be interested in adding all those tests?
  * Yoav: I’d be supportive
  * Npm: Would be good to have that test coverage.
  * Nic: Thanks!


    Current definition of startTime exposes total redirect time even
    when TAO fails #260
    <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/260&sa=D&source=editors&ust=1619499229876000&usg=AOvVaw1hPMjep_ALi9b42k6oPXn8>

  * Noam: startTime was the time right after redirects, which means that
    if one was to mark user timing just before starting the fetch, the
    can know the redirect time and extract information from this.
  * … The change that’s already in the spec is that start time is actual
    start time, meaning minimum value of redirectStart or fetchStart
  * Nic: There was some conversation on mitigating fetchStart on TAO,
    but now startTime = fetchStart
  * Npm: fetchStart is the initial fetch, not the final resource fetch
  * Noam: In the TAO fail case, the TAO pass case there’s no change to
    fetchStart
  * Npm: It will be the fetchStart of the final resource
  * … Doing something different in TAO pass vs. fail is potentially
    confusing
  * Noam: The embedder should be confused, because it’s not something
    that they should know.
  * Nic: They will still not know if there are any redirects because
    we’re only providing two real timestamps, which is start and end
  * … Wanted to make sure we’re not eliminating fetchStart because that
    could have compat issues
  * Noam: It’s landed
  * Noam: Added tests for some behavior changes, but not sure for this one
  * Nic: Are there any tests to validate these changes?  Should we
    “require” tests for any spec changes?
  * Npm: Would be nice to have. In WHATWG there’s “is this change
    tested” checkmark. Would be good to have that to ensure people don’t
    forget.
  * … Otherwise there’s no record of the change
  * Noam: I added a test for this one


    Render blocking status of resources
    <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/262&sa=D&source=editors&ust=1619499229879000&usg=AOvVaw32tXPLqIFAztb0XgiRgggl>

  * Yoav: Feature request that I thought I added years ago, but didn’t!
      So adding now
  * … Very recently added exposure of render-blocking scripts and styles
    to Chromium traces, for use in devtools and lighthouse and WPT
  * … Seems like a generally-useful concept for people to know when
    they’re loading a render-blocking resource, or loading non-blocking
    before LCP, or otherwise see what they are
  * … DevTools and Lighthouse were trying to guess that, based on type
    of resource and when it’s loaded and priority.  This is a good
    estimate but not always super-accurate.
  * … Seems useful initially, and I thought now that RT is cleaned up we
    can start finally adding new things to it
  * … Would require some spec around what a render-blocking resource is
    and isn’t
  * … Would love to hear your thoughts?
  * Nic: From a consumer’s point of view, where our customers have a lot
    of focus on visuals, this would be good to highlight resources
  * Benjamin: What kind of shape for this indicator
  * Yoav: Not a separate buffer, just an attribute for the
    ResourceTiming entry, enum that says non- or partial- or fully-blocking
  * … We have Fonts are non-blocking or fonts that are partially-blocking
  * … Thought it would be part of RT entry, not 100% sure what API shape
    would be
  * … After we get some experience with traces
  * … I’ve added it for scripts and styles but not yet fonts into
    Chromium traces
  * … There’s a non-blocking flag in HTML for script loading that I just
    reflected here, but it does weird things with dynamic async scripts,
    they’re considered blocking but they’re not really
  * … We may need to work on HTML definitions
  * Benjamin: As you experiment, I would be curious to see just the
    blocked elements versus both
  * Yoav: Right now only reporting it only for images that are possibly
    blocking, i.e. for IMGs there is no blocking status
  * Noam: I’m thinking the render blocking thing is a browser choice
    rather than a standard thing in most cases?
  * Yoav: I think in at least some cases it’s defined
  * … e.g. rendering doesn’t take place as long as there are pending
    styles (correct me if I’m wrong)
  * … I haven’t looked at the specification status of this, I assume at
    least for blocking scripts they’re blocking.  For styles and render
    blocking, it can be slightly more ambiguous, I’m not sure.
  * Benjamin: I expect there to be some vendor-specific parts of how
    they’re downloaded.  But for a show of hands, is this useful? Yes!


    Calls for Consensus

  * Yoav: This is a result of the call to action from the last few weeks
  * … For one of them, the request is to do nothing
  * … For the rest, we’re looking for objections.  Folks on the call
    were all supportive.
  * … My understanding is if no one objects, then we’re good and we can
    publish and move specs forward
  * ... If there are objections, please let us know
  * … Also if there are questions
  * Benjamin: Can I rep

- Nic
https://nicj.net/
@NicJ

On 4/14/2021 12:28 PM, Nic Jansma wrote:
> I'm bad with dates apparently.
>
> The meeting is: *Thursday April 15th*
> - Nic
> https://nicj.net/
> @NicJ
> On 4/13/2021 1:20 PM, Nic Jansma 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 14st @ 10am PT / 1pm ET) we will 
>> discuss:
>>
>>   * Discussion of the Meeting Recording Survey results (this portion
>>     will not be recorded)
>>   * Fetch and HTML integration of RT/NT
>>   * Issue triage for ResourceTimeline, PerformanceTimeline, Preload
>>
>> 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 (after the first discussion) and 
>> published online afterwards.
>>
>> See you soon!
>> - Nic
>> https://nicj.net/
>> @NicJ
>
Received on Tuesday, 27 April 2021 03:58:55 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 27 April 2021 03:58:57 UTC