Participants
- 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 Notes
- 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 developers)
- … 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 this
- … 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
- Yoav: We’ve discussed this in the past and I think we have a path forward
- Michal: I still want to tackle this issue, just haven’t had the time to yet
- Yoav: Need to try to nudge that along
- 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 thoughts?
- 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
- Yoav: Fold this into the other Fetch Observer issues
- Nic: AI to merge this into the other issues
- 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
- 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 together.
- … 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 perspective.
- Yoav: AI to comment on the issue
- 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
- 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
- Yoav: I believe there’s a better WebIDL issue to detect dictionary entries
- 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
- Nic: I think this is resolved
- ...: AI to close this out
[a]@mmocny@chromium.org
_Assigned to Michal Mocny_