Re: WebPerfWG call - August 19th 2021 @ 10am PT

 and recording <> are now available, and
published to Github

Nic Jansma, Yoav Weiss, Giacomo Zecchini, Alex Christensen, Benjamin De
Kosnik, Tom Mckee, Noam Helfman, Ian Marge, Sean Feng, Annie Sullivan,
Nicolas Pena Moreno, Ian Clelland, Michal Mocny, Boris Schapira

   - Will record the presentation
   - Next call is September 2nd same time
   - TPAC survey

   - Winner is 4 days in a row 8am-11am PST
   - We’ll follow up with an agenda and invites

Issue triage

   - Yoav: WebIDL defines a DOMTimestamp that is not widely used but used
   by some specs
   - ... May have been inspiration behind DOMHighResTimestamp
   - ... Proposal to fold into High Resolution Time spec
   - ... Fine from spec perspective, but maybe issues from process
   - ... Augment scope of High Resolution Time to cover non-high-res
   - ... Maybe we'd want to change the spec name to reflect that
   - ... Not sure if we'd need to change the charter
   - Benjamin: The move to HR time seems fine
   - ... Lean against renaming HR time as it could affect charter
   - ... Path of least resistance is to move and not rename
   - ... I don't think that'll be confusing
   - Yoav: We could also take the approach of moving it, not
   renaming/touching charter, and if confusion arises we can solve it rather
   than ahead of time
   - Benjamin: The impactful thing here is the change to double, would that
   affect this?
   - Yoav: Seems orthogonal, not sure it needs to happen here
   - ... Geolocation depends on it?
   - Benjamin: Option to move it, change it to double, and deprecate the
   old DOMTimestamp?
   - Yoav: Alternatively we could change GeoLocation and remove this
   - ... See from WebIDL folks if we can move into HR Time without renaming
   - Yoav: AI to sum on issue

   - Nic: PR by Sergio to update the diagram to make it clear that the
   unload event is not serial to the other events in navigation timing, as
   it’s not always happens before them
   - … Not too controversial, any feedback?
   - <crickets>

   - Nic: unloadEventEnd and unloadEventStart shared the same text
   - … Already addressed in the editors draft
   - … So this is already covered
   - Nicolas: Do we need to check if any published version has that issue?
   - Nic: Looks like it’s fixed in L2

   - Nic: Definition of initiatorType removed from the spec with Fetch
   integration, and we no longer have a list of that
   - Yoav: this is now defined in Fetch’s callers, so we could add a note
   and include links to places where they are defined (although not all
   callers are properly defined right now)
   - Nicolas: Should we also have an explanation in the README? Right now
   the spec is hard to follow, but maybe we need an explainer that’s more
   - … Would be good to add an explainer
   - Nic: I like that. We’d also need a link from the spec to the explainer
   - Yoav: We could also add a non-normative section with all that info.
   - … And now the question is - who’s signing up to do that work?
   - Nic: Is it just a copy paste from the previous spec?
   - Nicolas: It was a mix between explanation and spec. We want something
   that’s just explaining. We can look at the history and reuse some text, but
   I suspect we’d need to add some additional context
   - Tom: I can tackle this

   - Ian: stronger support for adding new types of events. Haven’t heard
   explicit support to try to use existing navigation entries.
   - Nic: I think this is the path being followed by App History. Did you
   get feedback about being able to observe all of them at once?
   - Ian: nothing specific about the API shape.
   - Nic: do you mind adding the feedback to the issue?
   - Ian: Sure, will do that
   - Michal: will we not have a common identifier for these different types
   of navigations? The idea is that other performance entries should be able
   to link to the navigation being used.
   - Yoav: whether we have a single place or multiple observers, I don’t
   think this impacts navigationId, and we can still do this across different
   navigation types.
   - Michal: current proposal doesn’t seem to expose that information. It
   seems like this might be more brittle. You’ll need additional listeners in
   different places
   - Yoav: What do you mean by multiple listeners? The question is about
   having the same entryType vs not, and I don't think this changes the code
   that much.
   - Michal: I interpreted the AppHistory proposal as not exposing
   performance observer
   - Yoav: I hope you’re wrong

Presentation: Rebooting the Network Information API

(* Thomas: Current API exposes

   - API can say 4G when you’re on WiFi which can be confusing
   - On mobile the type exposes “cellular” which can result in privacy
   - CanIuse shows Chromiums, Firefox for Android and KaiOS
   - In a little more detail, Chromiums contain the full information

   - “Type” only exposed on mobile

   - Firefox exposes connection type, but not e.g.
   `effectiveConnectionType`, which can cause breakage IRL
   - Very popular API: 40% of all page loads

   - Used in a lot of popular widgets: FB, Youtube, performance plugins and
   analytics tools (e.g. Wix)

   - Some overlap with use cases with SaveData API, which started as part
   of netinfo

   - Now SaveData is defined in a separate spec

   - Has privacy issues: Mozila considers it harmful, Apple objects to
   fingerprinting opportunities it exposes
   - TAG was generally positive
   - Maybe time for a reboot
   - Objectives for the reboot

   - Limit the shared data while enabling the same use cases
   - Triggered by issue #91
   - Driven by issues #85 and #84

   - Proposal


   - *shows code samples*

   - Download essential content but not more
   - Limit bandwidth usage - e.g. WebTorrent

   - Client Hints to accompany the JS interface that reflect the same values
   - Speed would be in coarse buckets growing exponentially, based on
   sliding window
   - Speed can be defined as infinity if UA considers it sensitive
   - Welcomes feedback
   - Alex: Question - used on 40% of page loads. Any data if data was
   actually reduced? Bytes used with the API indicating high bandwidth vs.
   low? Bytes used with savedata?
   - Thomas: No data. uses it for prefetch decision. Wix uses
   it for analytics. I don’t know if we measured bytes saved based on that.
   - Nic: Awesome attempt to get this information in a more standardized
   state. In mpulse we use ECT to bucket data. With sustained speed there
   would be tension between the observed throughput and the theoretical
   throughput. E.g. if the user navigated to slow websites and then went to a
   fast one, that would be different than a speedtest where they tried to
   maximize their connection. Dunno what the solution, but you could get
   different results depending on the background activity.
   - Thomas: Vendors could play with the sliding window and get more
   accurate info. You could also run your own “speed test” and download files
   actively. I was browsing the web and watched the speed meter, and it was
   pretty reflective of what I was feeling in terms of speed.
   - … Need to talk to Chrome eng to figure out what the implementation
   would look like. I kept it vague on purpose so that conservative browsers
   from a privacy perspective can still implement this.
   - Nic: Let’s continue discussion on the document

- Nic

On Wed, Aug 18, 2021 at 2:03 PM Nic Jansma <> wrote:

> Hi everyone!
> On the agenda
> <>
> for our next call (Thursday August 19th @ 10am PT / 1pm ET) we will discuss:
>    - TPAC 2021 scheduling
>    - Long tasks integration with JS Self-Profiling
>    - NetInfo proposal update
>    - Issue triage with ResourceTiming and NavigationTiming
> Plus any other issues you want to talk about. If you have additional
> items, please add them to the agenda
> <>
> .
> Join us <>!
> The presentation portions of the meeting will be recorded.
> See you soon!
> - Nic
> @NicJ

Received on Saturday, 21 August 2021 16:37:13 UTC