Participants

Yoav Weiss, Nic Jansma, Philippe Le Hegaret, Alex Christensen, Noam Helfman, Gilles Dubuc, Dominic Farolino, Sean Feng, Neil Craig, Nicolás Peña, Carine Bournez, Andrew Comminos, Michelle Vu, P Perl, Michal Mocny, Annie Sullivan, Steven Bougon, Nate Schloss, Ben De Kosnik, Chris Harrelson, Ryosuke Niwa, Philip Walton

Next Meeting

September 10th @ 10am PST

Hackathon

• Yoav: We had talked about running 1-2 days of working through issues prior to TPAC
• … Timezone wise, it would be better to have several half-days
• … Schedule around this time on Tuesdays in September, 3 or 4 half-days
• … I will send out invites, and alert the mailing list so others can attend as well

Incubation CFC

• https://lists.w3.org/Archives/Public/public-web-perf/2020Aug/0005.html
• Yoav: Send out a mail a few weeks ago to see if there are any incubations that we want to invite into the working group
• … There was some discussion on the thread and would like to bring some of those into this call
• … Benjamin, you had brought up some questions and would like to see if you could explain more here.
• Benjamin: Timing wise, is this related to rechartering?
• Yoav: Somewhat related, I think most would be covered by the existing charter, but some could be included as deliverables
• … We could amend the charter later
• … I think we agree the use-cases those incubations attempt to solve are valuable and are worthwhile to collaborate on
• … They don’t have to be included in this group, but to ensure we’re all comfortable discussing those issues on these calls, which can increase visibility and collaboration
• Benjamin: I’m a little uncomfortable because I don’t think there is multi-vendor consensus, and would prefer to keep them in WICG.  I don’t see any harm in keeping them out of W3C right now
• … In the future if we get more consensus between vendors that’s a good point to move to the W3C
• Yoav: Does that apply to all of the incubations, or just some? E.g. isInputPending
• Benjamin: Did we reach consensus on the call when discussed?
• Yoav: I believe so at the time, yes
• Ryosuke: At this time Webkit isn’t interested in implementing these
• Yoav: In the past we’ve included some proposals that have lagged in implementation in other vendors.  Do you object to these specifications being worked on here?
• Ryosuke: If this is going into future rechartering, we don’t want to limit our participation in this working group.  My preference is not to have them.
• Yoav: Benjamin from Mozilla’s perspective?
• Benjamin: We don’t have clear consensus, we don’t have a formal objection.  I would repeat my request to delay this.
• Philippe: What about the users’ perspective?
• Steven: For Salesforce, we would like to have these APIs available, only one may not be suitable for us
• Yoav: Do you feel that these incubations should be adopted in the working group?  Not what various engines will implement and ship?  Whether these should be brought into the working group or stay as incubations for now?
• Steven: As a user it’s hard for me to say what the difference is.
• Gilles: What’s the practical difference for us?
• Yoav: From your perspective, the various issues will be discussed as part of the WG calls and issue triage, as opposed to just in Github issues.
• … My hope is having that visibility will get us closer to multi-vendor consensus and implementations, but those are not tightly coupled.
• Rysokue: I’m sympathetic to some of the use-cases, but my main concern is some of the solutions these cases present
• … The most practical solution difference between them being in the WG or not is if they’re part of the charter and deliverables, which have IP implications.
• Yoav: The intent with adoption would be to add them as deliverables, so having Apple’s position on that angle would be useful
• Nic: Akamai has a broad interest in all of these specifications, and would prefer to be able to discuss these openly in the WG with multiple stakeholders, vendors, and users.
• Steven: Is the concern that if we brought them in as a deliverable, and Apple wouldn’t be interested in delivering them, is that the concern?
• Yoav: I think the concern is more around the IP implications of bringing them into the working group.
• Ryosuke: It’s not that we’re not interested in the use cases, just that we would need to do additional research if we were to bring them in
• Philippe: I think all of them live within the scope of the working group’s current charter
• Ryosuke: Concern is that in today’s multi-vendor client that one vendor proposes a feature, implements it, and websites start using it right away.  The impact of that locks in a solution before there was discussion and consensus.
• … We don’t think any of these specifications are good solutions to existing use cases
• Yoav: It’s hard to talk about this in the abstract, so if we just talk about ElementTiming and LCP for example, we’ve been talking in this working group about providing measurable visual elements for at least 5 years.  The use case is something people are interested in measuring, that we’ve been discussing here for a long while.
• Ryosuke: There have been multiple proposals for solving these problems, and I have raised multiple questions and issues about ElementTiming and LCP.  So why do we think they’ve been incubated enough and in a good state to be moved into the Working Group.
• Yoav: We’re not trying to move those to CR or PR.  We’re trying to get them adopted as Working Drafts.  There’s not necessarily a quality bar here.
• … At the same time I understand is that we don’t have consensus
• Ryosuke: Here specifically I’ve raised concerns about all of these implications in the past
• Nicolás: Can you be precise about feedback that was ignored?
• … I would like to clarify what we’ve addressed
• Ryosuke: I don’t feel that any of these APIs are appropriate for any of the use cases
• Yoav: My recollection for LCP specifically, it was presented multiple times to the WG, and you and others raised concerns, and Annie presented data to address those concerns.
• … From my recollection from that meeting the initial skepticism was addressed.
• … If that’s not the case it may be useful to point out again what concerns we have
• Ryosuke: The data was specifically from Chrome, which is how Chrome paints.  We do not believe that would work in Safari because our painting model works the same as others.
• … Also, what’s important during page load is very subjective and what you value for user experience.
• … As an implementer, we have an objection to having LCP as a metric, as that might encourage developers to optimize the wrong thing for Safari
• … Yes, these are things we should discuss in the working group because we agree on the underlying use case
• … What is the distinction we should make between the things that should be incubated and the things that should be brought into the working group
• Yoav: Regarding the painting differences between different engines, I was under the impression that we more-or-less defined as part of FCP and maybe ElementTiming and LCP should benefit from similar definitions for all engines.
• … Otherwise, the question regarding when incubations should be adopted, is not necessarily a well-defined line
• … This was something mostly working-group driven, there is no strict criteria.
• … When does this working group think an incubation has been defined well enough that we want to bring it into the working group for discussion
• … This was a call for consensus, and we don’t currently have consensus
• … If there are some incubations in that list which may have more interest than others, such as isInputPending which we verbally agreed to adopt but didn’t send an official CFC.
• … Benjamin had asked for an extension until TPAC, which we could wait for re-discussion
• Benjamin: Something to think about is automating that process, to get a show of hands every 6 months.  Might be helpful to get us towards consensus.

Preload => HTML

• https://github.com/w3c/preload/issues/154
• Yoav: Requests to integrate more parts of Preload into the processing model of HTML
• … Having Preload defined in HTML but have its own separate spec is confusing
• … One solution for that is to merge all of the existing processing model into HTML, publish a note, and move all Issues to the WHATWG
• … Strong opinions?
• https://github.com/w3c/preload/issues/147
• Yoav: Move the parts related to the processing model into the HTML specification
• Philippe: If we move the processing model, we should move the markup as well, and if we do that there’s nothing left
• Ryosuke: Makes sense to me to merge it into HTML, given the rest of the LINK element processing is in there
• Benjamin: Agreed
• Philippe: Moving from W3C to WHATWG or vice versa, both organizations have to agree
• … Bad news is you’re number 4 or 5 on the review list, and meetings have been spotty at best.  Might take a month or two before we can get back to you.
• Yoav: I don’t think any of this is urgent
• … Seems like it would reduce confusion
• Philippe: I will take an action item to bring this up, but it may not happen before TPAC
• Yoav: Yes, please

EventTiming vs. Long Tasks

• https://lists.webkit.org/pipermail/webkit-dev/2020-August/031329.html
• Nicolás: webkit-dev thread about Event Timing
• … Wanted to clarify use-cases and differences between Long Tasks and Event Timing
• … In particular, there was some concern about Long Tasks that it’s already adopted, that maybe Event Timing solves similar use cases.
• Alex: webkit-dev thread asked if there was overlap
• Nicolás: For Long Tasks, one use case is detecting if a website can respond to user-input quickly.  There are other use cases, such as to ensure that animations that run on the main thread run smoothly, because if you have Long Tasks that might not be possible.  Another is that CPU usage can be linked to consumption, as you can look at Long Tasks to try to keep the battery usage as low as possible.
• … You can also compute various metrics based on the Long Tasks, such as Sum of Long Tasks to help link to CPU time, or to compute metrics like Total Blocking Time which measures how much of time on the site is user-perceivable.
• … There are some other use cases for example some ads teams use Long Tasks to compute metrics on the impact of ads on websites.
• … Overall some analytics providers use them to try to fix performance bottlenecks.
• Noam: We use them generally the way you describe it as Total Blocking Time (TBT) to grade sessions’ user experience, then use other session telemetry to analyze where the bottlenecks are and where to improve our code.  Very useful to us for our use case.
• Steven: We also use Sum of Long Tasks to understand if the slowness is due to the underlying hardware or the backend.
• Nicolás: We can compare that to Event Timing.  Notice not all of Long Tasks are related to events.  Event Timing tries to capture timing of events that actually happen.  It’s hard to predict when a user-input is going to happen.  So you can’t use Long Tasks to measure input delay, the time when the user actually clicks is hard to predict.
• … Event Timing solves use cases related to directly measuring delays in responding to user inputs.  One of the metrics Event Timing allows is measuring First Input Delay, which we’ve defined previously in these calls: for the first meaningful user interaction on the page, how long does it take for the user-agent to start handling the event.  I.e. for a click or a tap, how long does the UA take to dispatch the pointer-down related to that interaction.
• … Does not measure how long it takes for the UA to actually handle it, but just dispatch the event.  But it does allow you to also measure how long it takes event handlers to run.  (Any async tasks posted during the handler are not measured yet by the API)
• … The final component it measures is how long it takes the UA to update the screen based on the interaction.  Assuming the screen is updated from the user interaction.  Exposes the time it takes for the next paint from the user interactions.
• Michal: Long Tasks seems to be good at predicting issues, battery usage.  For smoothness etc it’s a predictor.  For Event Timing it results in the actual data bound to the event itself.
• Ryosuke: Issue here isn’t the use cases, that there’s so many APIs and how do they all fit together?
• … For Event Timing, one of the cases is measuring how long the UA takes to resolve.  But in today’s modern apps, we have a lot of async/promises/etc.  Need many APIs combined to see how long the user input took to get to the screen again.
• Nicolás: Proposal is to address that use case with Event Timing, but we’re not there yet.  It’s hard to measure causality. That’s a problem we’re hoping to address at some point.  We think this is a good first step towards that problem.
• … Frame Timing is more geared towards smoothness of animations and scrolling, different than measuring how long tapping takes to produce a response
• Yoav: In the scenario you propose, it’s hard to measure the full async nature of it.  But we’re creating the building blocks for developers to help bridge the gap of asynchronous calls if that is of value as well.
• … Ideally we would have a high-level API, but a set of low-level APIs that are building blocks doesn’t sound like a bad outcome
• Ryosuke: Not sure if these are the right primitives
• Yoav: Are there alternatives that you would consider a good API that would solve these issues?  As Nicolás says this API could be grown into that.
• … Let’s continue this discussion next time