Re: WebPerfWG call - January 7th 2020 @ 10am PST

Hey folks,

recording <> from the call are now available.

Minutes are now on Github, so there's no real archival need to copy them
here. I'm still doing that in case that's helpful to get them in front of
folks. Let me know if you have opinions on that either way.


   - Nic Jansma, Yoav Weiss, Alex Christensen, Will Hawkins, Nicolás Peña
   Moreno, Carine Bournez, Ulan Degenbaev, Peter Perlepes, Annie Sullivan,
   Michal Mocny, Nolan Lawson, Steven Bougon, Andrew Galloni

Next Meeting

January 21st @ 10am PST

Yoav: Looking into field of client-side A/B testing and performance problems

… Would like to run a WG open meeting in a month or so

… Early February either as a replacement for regular call time, or an
extended call
Meeting NotesMemory Measurement API - bikeshedding discussion
Ulan Degenbaev

   - Rename bytes to userAgentSpecificBytes · Issue #11 ·

   - Ulan: Naming problem that’s been open for a while
   - … Just an API on the performance object, returns a Promise
   - … Describes current memory usage in bytes, breakdown
   - … Bytes in the result are currently user-agent specific, cannot be
   compared between browsers
   - … Naming doesn’t reflect that
   - … Feedback from Mozilla, issue to resolve
   - … Should we stress in the name that it’s UA specific
   - … Option A: Keep current naming
   - … (only available in isolated contexts, not available for many
   - … Option B: UA-specific in API name
   - … Option C: UA-specific in results fields
   - Michal: Have we come across this issue in any other designs or specs?
   - Yoav: I recall this happening before but don’t recall where we landed
   - … We should look for precedence in past to align to
   - … For this I think we do need to outline that this is UA-specific, no
   opinion on B/C is preferred
   - Steven: Are we trying to do something like CSS with the prefix?
   - Yoav: Not the same as CSS prefixing, the API is the same, just the
   result will be different between UAs and we don’t want developers to
   compare two browsers
   - Steven: Proposal is not to include vendor name in the API, just that
   the API results may vary by browser and can’t be compared
   - Ulan: Most APIs are around time, whereas memory is another dimension
   - Michal: In WebKit, firstPaint is different than others where it waits
   until there is content
   - … I can see why memory is a little more sensitive, this seems like a
   lightweight way to address this concern.
   - Ulan: One concern with B, if we add “uaSpecific” string in API, other
   APIs may also use it
   - Nolan: The goal is to avoid web compatibility issues.  Originally we
   had UA-specific types array in the API
   - … What would a web compat bug look like in this situation?
   - … i.e. would they look at bytes and decide to go into low-mem or
   high-mem mode
   - Nicolás: Are the use-cases of the API to take action based on the
   value returned?
   - Ulan: More for regression testing results, to collect telemetry data
   and detect regressions over time or build
   - … Aggregate results are meaningful and individual results are less
   - Nicolás: Not sure if butchering the name with “UA”, where developers
   even know what it means
   - Alex: I like option A, pretty obvious that different UAs may differ
   - Michal: There was an alternative or past version where you’d need a
   large switch to make sense of the data.
   - Nicolás: There’s definitely still UA-specific types, but they’re named
   that way
   - Yoav: Main concern is when interpreting results users will compare
   numbers in places they shouldn’t.
   - … I think that could be addressed in documentation instead of the
   function name
   - … There’s no real web-compat risk associated with that behavior, it’s
   just an understanding problem
   - Sean: I prefer B, other performance timings we do use them to compare
   between browsers, to label it as UA-specific might make sense
   - Nic: I think it comes down to whether we want to documented the
   intricacies of this in the API name versus the spec.  My take is the spec
   gives us a lot more opportunity to talk about the issue in the spec.
   - Nicolás: May just need better developer outreach. Changing the name
   might help some people, but many may still not understand what it means.
   - Andrew: I don’t think adding “UserAgentSpecific” would stop people
   from doing comparisons
   - Yoav: Seems like most people on this call, except Sean, are more
   favorable for Option A, but maybe we should give more folks time to review
   - … We’ll note group’s preference in meeting, but let other folks who
   have a strong opinion have time to weigh in on the issue

Unexpected HTML things to check · Issue #51 · w3c/page-visibility

   - Yoav: We’ve discussed this in the past and I think we have a path
   - Michal: I still want to tackle this issue, just haven’t had the time
   to yet
   - Yoav: Need to try to nudge that along

Bring back support for prerendering page state · Issue #69 ·

   - Yoav: We discussed this on the call last month, during the call we
   decided to run an analysis on the various states
   - … We decide to land on a new event or state
   - … Should this be wrapped up into PageVisibility or should it go into
   HTML directly?
   - … Has anyone from Apple or Mozilla had a chance to review or have
   - Nicolás: For the HTML question, it seems easier to put it directly
   into HTML.
   - … Completely separate from visibility state
   - Yoav: Since it’s orthogonal to visibility, it might be strange to have
   it in this spec
   - Sean: Will take action item

Why not consider to add "fetchStart" event?

   - Yoav: Fold this into the other Fetch Observer issues
   - Nic: AI to merge this into the other issues

Are fetchStart, connectStart, redirectStart relative to navigationStart? ·
Issue #237 · w3c/resource-timing

   - Nic: I believe this is just a support issue, where the user may need
   to adjust his math
   - … AI, I’ll ping the user to see if they still have a concern

transferSize might reveal HttpOnly cookies · Issue #238 ·

   - Yoav: Discussed a month ago. Would make sense to remove cookie sizes
   at least from transfer size
   - Nic: also talked about removing transfer size entirely. One of the
   things I don’t think we discussed a lot in the last discussion was using
   transferSize to detect cache state
   - Yoav: If we were to remove transferSize, I think we could expose
   specific cache states: both full transfer and revalidation-only transfer.
   - Nic: We definitely rely on transfer size to heuristically estimate
   both those states.
   - … Alex, I know you had not yet implemented transfer sizes, would doing
   either of these help with implementation?
   - Alex: We’re not interested in exposing the pre-decryption transfer
   size. Eliminating cookies won’t necessarily solve the problems, would be
   more comfortable with removing headers altogether.
   - Yoav: Regarding exposing cache state and cache-revalidation state, are
   there problems with that in a double/triple-key’d world?
   - Alex: Not that I can think of right now, but that doesn’t mean there
   aren’t any
   - Yoav: What I think I hear is that you’d prefer to remove headers all
   - … Then we can separately discuss cache states.
   - … Sean, do you have any Gecko opinions?
   - Sean: I don’t know enough to comment on this
   - Nicolás: I don’t think there are very strong use-cases for header
   sizes. One is to catch large headers, but that’s likely to have issues, so
   we may have to give up on that.
   - Yoav: The main hurdle from a webcompat perspective would be the folks
   using transfer size to detect caching, but need to think how to tackle
   that. TransferSize that’s iidentical to encodedBodySize would enable folks
   to know if nothing was fetched, but for the case revalidations, they’d have
   a zero length, which is indistinguishable from full hits. We can provide an
   alternative and nudge people in that direction.
   - Nicolás: … Can we make pre-defined size regardless of header size for
   these cases?
   - Yoav: Yeah, that would be a good path forward from a compat
   - Yoav: AI to comment
   the issue

Ensure tests are clean

   - Yoav: Just a few failing tests on Firefox and Safari before we can
   move it forward
   - … Alex and Sean can you take AI to find someone to review issues?
   - Alex: Yep
   - Sean: Yep OK

Reset the observers

   - Yoav: Issue that essentially asks for better reporting for SPAs
   - … Known issue but not a simple solution
   - Michal: The specific request here is likely not feasible, but
   otherwise there’s plenty of ongoing work in other places
   - … I’d be OK with closing it and referencing in some other issues
   - Yoav: Maybe you can open a new AI that covers the broader ask and
   close this one while pointing to it[a]
   - Michal: Yep

Hard to feature-detect observe() parameters

   - Yoav: I believe there’s a better WebIDL issue to detect dictionary
   - Nicolás: Yeah the current way is painful for a developer that sees the
   new “type” and wants to move to it from their previous code
   - Yoav: What’s the level of urgency here, should we come up with our own
   hacky way to detect
   - Nicolás: I think “type” is already supported everywhere
   - … Might affect us in the future
   - Nic: Such as the “bubbles” flag
   - Yoav: Maybe we should close this as not an issue currently, but make
   sure to review when we add a new flag in the future
   - … AI to add an external-dependency label

a bit confused with the "Redirect" timing in Time Navigation · Issue #132 ·

   - Nic: I think this is resolved
   - ...: AI to close this out

_Assigned to Michal Mocny_

On Wed, Jan 6, 2021 at 3:06 PM Yoav Weiss <> wrote:

> Happy new year folks!
> Let's gather <> tomorrow to talk
> about WebPerf issues!
> On the agenda
> <>
> we have a bikeshedding discussion related to the Memory Measurement API, as
> well as a bunch of issues to triage.
> As always, the call will be recorded and posted online.
> See y'all there! :)
> Yoav

Received on Monday, 18 January 2021 15:33:36 UTC