- 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