Re: WebPerfWG call - April 23rd @ 10am PST

Hey all,

Minutes
<https://docs.google.com/document/d/e/2PACX-1vSduIea0ImwkiVzFaD3ZmMv4YO-EGxw6kG-btBR4yeavTCO1lUoL1haM3yz6GAvj_b2Ya82PpezI0CF/pub>
and video <https://www.youtube.com/watch?v=t8cSt6blmfM> are now published.
Copying the minutes here for safe keeping:
WebPerfWG call - April 23 2020
Participants

Yoav Weiss, Philippe Le Hegaret, Steven Bougon, Annie Sullivan, Benjamin De
Kosnik, Nicolás Peña, Michal Mocny, Alex Christensen, Dominic Farolino

Next call

May 7th 8am PST / 11am EST
Rechartering

WebPerfWG charter 2020
<https://www.google.com/url?q=https://docs.google.com/document/d/1K6l5JlEaUq9eSBNI9HGoLfeN9hpXLHlHPRW-WTjtBlU/edit%23&sa=D&ust=1588258909737000>

Yoav: Current charter expires June 30
... Drafted a new charter based off current 2018 charter, not a lot of
changes
... Please review and leave comments
... Thinking about larger themes like SPA performance, Runtime performance,
UX metrics (e.g. like Layout Instability), and making sure privacy and
security are prioritized - e.g. by integrating with the work that WebAppSec
is doing on Isolated Contexts.
Steven: “SPA performance” - awesome!
Philippe: I like the focus on privacy and security.  Would like to make
progress on issues around HR time.
Yoav: Also, WebAppSec are working on new primitives - COEP and COOP and we
need to integrate with that.
(no objections)
Yoav: Question regarding incubations. We have a long list of incubations
that were presented to the group and it is obvious that once they graduate,
they’d graduate into WebPerfWG. I want to get a sense of which of them are
already ready.
Philippe: We can also prioritize them.
Yoav: Going over them one by one...
... Event Timing: Measures delays in input events, First Input Delay part
of it.  Shipped in Chromium.
Nicolás: What are the criteria for adoption?
Benjamin: Can we tie these back into the larger themes above?
Yoav: Event Timing ties into Runtime Performance theme. Enables to measure
frustrated users in the wild. Every entry is indicating a case where the
site failed to quickly respond to user input. Looking for appetite to
implement (from implementers) and to adopt (from web developers)
Nic: From Akamai's POV, we like that Event Timing provides a more accurate
and reliable way of measuring FID and other event measurements. We
currently polyfill it, but this would enable a more reliable way.
Steven: Would be able to provide offline feedback for each of these after
we've reviewed them
Yoav: Can we take this as offline homework for everyone?  Please add your
comments as level of interest for adopting these proposals
Benjamin: add priorities?
Yoav: Don’t really need priorities, as there’s no quota to how many we can
adopt. Looking for positive/neutral/negative signals
Nicolás: Suggestion to send a request for those comments out to the list
Yoav: Further down the document there are additional questions around
charter language, I can take offline with Philippe
… Any further comments please provide in document above
Issues DiscussionRegistryRegistry should define algorithm for observer vs
entry
<https://www.google.com/url?q=https://github.com/w3c/timing-entrytypes-registry/issues/12&sa=D&ust=1588258909741000>
 (Nicolás)
Nicolás: As the spec is right now, every observer receives every entry of
the given entry tytpe
Nicolás: Proposal to add algorithm, when adding entry for a
PerformanceObserver, to make sure it's eligible to be added
Nicolás: For example, if someone wants to define a minimum
threshold/duration to be notified on (e.g. EventTiming, LongTasks)
Nicholas: Over time if we add additional parameters to the .observe()
method, we can add a link to here so the algorithm can decide if it wants
to add the entry to the observer.
PR: Add column for algorithm of observer vs entry
<https://www.google.com/url?q=https://github.com/w3c/timing-entrytypes-registry/pull/13&sa=D&ust=1588258909742000>
Yoav: These algorithms would be added to those specs directly
Philippe: As long as the normative bits go into the spec, that’s fine.
(no objections)
HR-Time3 Issues
87: Provide hook for getting a high resolution time between time origin and
a "time"
<https://www.google.com/url?q=https://github.com/w3c/hr-time/issues/87&sa=D&ust=1588258909743000>
88: High resolution time is not defined
<https://www.google.com/url?q=https://github.com/w3c/hr-time/issues/88&sa=D&ust=1588258909744000>
89: Make high resolution time dependant on cross-origin isolated
<https://www.google.com/url?q=https://github.com/w3c/hr-time/issues/89&sa=D&ust=1588258909744000>
Yoav: Main question is regarding publishing.  This is HR Time L2 work,
which is already in REC.
Philippe: Substantive change requires going back to CR. Editorials don’t.
Michal: Issue 87 and 88 seem editorial, 89 may have more substantive
question
Yoav: Right. This would make it mandatory to coarsen the timers in
cross-origin isolated contexts, which is a primitive that’s in the process
of being shipped.
… SharedArrayBuffers will be blocked on Isolated Contexts - when COEP, COOP
are enabled. Seems reasonable to also coarsen hr-time outside of those
contexts.
Nicolás: Open question on what would be the new coarsen value
Yoav: That’s indeed a question.
... Is this change a big enough change to justify L3?
Tangent on Living StandardsNicolás: Related question, is there an update on
moving towards living standards?
Yoav: not yet on the table
Philippe: There is a process being proposed.
… This group last time we talked wanted to be able to do either versioned
or living standards.
… Since we will be chartering soon, if we want to adopt living standards, I
would suggest delaying rechartering for Process 2020 to be adopted.
Benjamin: let’s do that!
Yoav: Are we interested in a living standard for some of these specs?
Nicolás: For HR Time it makes more sense for example
Steven: Can someone go over the differences between living standard and
versioned?
Philippe: Depends if versioning is important (e.g. for marketing purposes).
If we don’t care about versions, living standards are better.
Yoav: Currently, specs start as Working Draft, as implementations come
online it goes to Candidate Recommendation, then to Proposed
Recommendation, then Recommendation.
… If new features want to be added, then we would create a new "Level 2"
then "Level 3" etc
... For Living Standard, you start out new as a Working Draft, then
Candidate Recommendation (where you get patent commitments).
… Then you update the CR as you go. So the spec is never “done”
Philippe: The two are not incompatible, with Living Standard you can
snapshot a release off a specific version.
Benjamin: The living standard model sounds much better.
Yoav: Living Standards model is nice because it maps closely with software
development, where you add features then release a version.
… On the other hand, with versioned, we have checkpoints that help align
implementers to make sure everyone agrees on the current direction of the
specs.
… Would be great to get the benefits of both, maybe by adding a WG-specific
process, to make sure we’re on the right path to interop.
Philippe: Transitions like moving to PR can help trigger privacy/security
reviews, but we can introduce that as a WG process
... Part of the story is how we expose the spec to the outside world as
well.
… Haven’t presented the process to the chairs yet, waiting for it to be
finalized
Yoav: Will send a poll to the mailing list about (1) incubations we may
want to adopt and (2) Living Standards vs. current process.
... If there is appetite for Living Standards model, we may want to ask for
an extension to the charter
Philippe: As long as the current charter doesn't limit us, an extension
doesn’t hurt
Benjamin: Can you explain about Process 2020, chartering now vs. waiting 6
months?
Philippe: If we want to adopt Process 2020 in 6 months, we would have to
re-charter then too (or wait another 6 months).
… It includes Living Standards plus patent review changes.
Philippe: Even if we choose not to adopt Living Standards, we will need to
recharter per Process 2020 soon anyway
Benjamin: Let's formalize that question
Yoav: Post a CFC to mailing list regarding if we should re-charter right
now or get an extension and wait for Process 2020
Back to HR-TimePhilippe: Regarding Anne's questions, let's get the changes
made to the head of the repo and we can decide after re-chartering what
version to bring it into
Yoav: Also not sure how ready the specs around isolated contexts are.
Worst case, we could hand-wave the definitions for now and update the links
later
Michal: Are there any larger tracking issues around those primitives right
now?
Yoav: Not a larger one, but there are PRs to land COOP/COEP into the HTML
spec.
COEP PR
<https://www.google.com/url?q=https://github.com/whatwg/html/pull/5454&sa=D&ust=1588258909752000>
, COOP PR
<https://www.google.com/url?q=https://github.com/whatwg/html/pull/5334&sa=D&ust=1588258909753000>
... : Isolated Contexts
<https://www.google.com/url?q=https://github.com/mikewest/securer-contexts&sa=D&ust=1588258909753000>
ties
all this together to something we can rely on in HR-Time
Philippe: Makes sense to have an issue in HTML that tracks all of the
changes that need to be made once it lands
... can we assign someone to the issues?
Yoav: I can take that on
Server Timing2 maintenance issues
Issue 68: Multiple trailer "chunks" each containing server-timing
<https://www.google.com/url?q=https://github.com/w3c/server-timing/issues/68&sa=D&ust=1588258909755000>
Issue 69: Creation time of PerformanceServerTiming objects unclear
<https://www.google.com/url?q=https://github.com/w3c/server-timing/issues/69&sa=D&ust=1588258909755000>
Yoav to follow up with Charlie to see if he can help maintain
Issue 65: Using Server-timing to carry TraceID
<https://www.google.com/url?q=https://github.com/w3c/server-timing/issues/65&sa=D&ust=1588258909756000>
Philippe: From Distributed Tracing WG
... Useful for tracing requests through multiple components of your
infrastructure/cloud/microservice
... Would like browser to also track and care about this information
... More recently they are thinking of using other headers to carry this
information, so we can close this particular request out
Yoav: It sounds OK to use ServerTiming to carry Trace ID, but I don’t see
the browser carrying this information from one server to another
automatically, as that’s a cross-origin communication mechanism that we
probably don’t want to create.
… They can have analytics scripts that read Server Timing entries from
multiple providers and send them to a single collection point. Server
Timing already supports that.
Philippe: Can you say that on the GH issue?
Yoav: yup




On Wed, Apr 22, 2020 at 11:44 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey folks!
>
> Let's talk <https://meet.google.com/agz-fbji-spp> about WebPerf tomorrow!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.gybubtpgvx0e> we
> have rechartering
> <https://docs.google.com/document/d/1K6l5JlEaUq9eSBNI9HGoLfeN9hpXLHlHPRW-WTjtBlU/edit#>
> (!!), as well as a few issues to discuss related to Performance Timeline's
> registry, HR-Time and Page Visibility.
>
> As always, the call will be recorded and posted online.
>
> See y'all there! :)
> Yoav
>