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
- 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 Discussion
Registry
- 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.
- 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-Time
- 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 Standards
- Nicolá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-Time
- Philippe: 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.
- ... : Isolated Contexts 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 Timing
- 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