WebPerfWG call - September 10th 2020

Participants

Nic Jansma, Yoav Weiss, Benjamin De Kosnik, Andrew Galloni, Carine Bournez, Peter Perlepes, Nicolás Peña, Sean Feng, Chris Harrleson, Michal Mocny, Phil Walton, Thomas Kelly, Michelle Vu, Dom Farolino

Next call September 24th @ 10PM

Minutes

Largest Contentful Paint

Call back to indicate that the observer is about to stop (Nicolás)

Final LCP slides
Nicolás: Currently hard to know when the LCP algorithm stopped
… Also a problem when the page is hidden, as timestamps after that are not useful, because no paints happen when the user is in the background
... So wanted to present “Final LCP”
... Problems: latest candidate with lower start time
... e.g. image vs. text where the image takes longer to load and doesn’t have TAO
... Also the fact that removed elements are no longer LCP candidates complicates things
... Could have a large image loading by the time the user is loading the page (or unloads the page)
... So LCP wasn't "reached"
... Any user of the API would just assume the last candidate was the LCP
... No reliable way to know when LCP has stopped. Users may look at page visibility, but it’s hard to know when to stop based on inputs, and adding event listeners is an anti pattern
... Currently developers can listen forever, but the latest is not guaranteed to be the actual LCP, and waiting forever is not practical
... Proposal, expose final-lcp when algorithm stops (user input) or when page becomes hidden.
... Thinking of adding a separate entry type
... Alternatively, we can break the current users and override the current LCP semantics
... Similar to FCP, so could be exposed in the performance timeline
... Need to specify that the entry is available before visibilityChange fires
Nic: So the only time we’d be able to emit this final-lcp is on user input or when the page is hidden. So it won’t be available at `onload`, right?
Nicolás: Right. Do we final-lcp at first-hidden or as it gets unloaded? The first hidden is the true place where you’d stop looking at LCP.
Nic: For Boomerang, we capture LCP. We beacon up at onload time, so if we continue capturing that this way, a single beacon at page load event, we’d probably never see this final LCP, because we don’t wait that long
Nicolás: What happens if onload is early?
Nic: For SPAs we do something else, but waiting for the page to finish activity and then beacon things up
… but not waiting until the page is hidden to send the data
Nicolás: So if you don’t change the way you send the data, this will not work for you?
Nic: Not in the way we send data today.
... Most other analytics packages also send data earlier.
... You can do some stitching together of data at the back-end if you want to to send two beacons (at onload and unload/hidden), but that can be more complex
Nicolás: Have you found the visibility change event to also be unreliable?
Nic: There’s also a balance of trying to get realtime data. We try to send some data early on
… We do send beacons on unload, but we get ~70% of beacons. About 30% of the time unload doesn’t fire
Nicolás: So seems like we need to keep the candidates around -- less reliable but may be easier to use
Phil: Question for Nic - do you track the first visibilityChange as well? Do you know what its reliability is?
Nic: We log those timestamps if they happen before onload, but don’t beacon at that point
Phil: Would you be able to also send a beacon at visibility change?
Nic: We try to send the data at page hide…
Phil: Trying to get real world reliability of visibility change
Michal: As a followup, what about post load analytics?
Nic: Measure LayoutShift up until the load event. Stitching is possible, but tradeoff vs. real time analytics
Benjamin: Naming - Final LCP is not great. Can we do First and Last?
Nicolás: What does Last mean here in that context though?
Benjamin: I'd like to expose the range of paints
Yoav: I've heard of folks gathering LCP and are having trouble understanding when the last LCP candidate has fired.
... Not a big fan of "Final" here -- there could be additional paints that are smaller
Nic: For an SPA, there could also be more paints happening
Ben: Would it make sense to split out SPAs from this discussion?
Nicolás: Even for MPAs, “last” can be confusing because there can be paint following user input. This is the “largest” paint before that.
... Take a point on “final” not being great. More important - who wants this?
Nic: We alone don't represent the industry! Sees the value in ergonomics.
Yoav: If you could replace the load event you have with paints, would it be a good event to hang analytics on?
Nic: Potentially, combined with a timeout
Andrew: We’d be interested in such an event
Peter: Makes more sense than adding event listeners
Nic: To move forward on this issue - should we solicit more feedback first?
… I can reach out to get more eyeballs on the proposal
Nicolás: And we should consider better names

Preload

preload #147 - "Delay the load event" should happen in HTML

Nic: Should we discuss that at all?
Yoav: Probably not

preload #153 - Remove "Dependencies" section

Dom: If we're going to moving the spec processing model into the HTML standard anyways, is it worth doing these now?
Yoav: I don't think we need to do that, we can see with Philippe when the move to HTML will happen

preload #149 - Add an attribute to hint the server which headers to copy in push requests

Yoav: Underlying issue is people want to add hints to servers to modify the way H2 push is done
... Two issues: Whether it makes sense to add content-based hint for servers to do what they currently don't do
... Somehow sneaked various push-related behaviors into preload, and we maybe shouldn't have
... Doesn't make sense to define those server-push related behaviors in the preload spec
... Would rather it happen as part of server push, separated from preload
... There's also "nopush" which isn't really defined anywhere but is used in examples here
Andrew: I agree
Yoav: AI to comment on the issue and open a separate issue that push-related hints should be split apart

PerformanceTimeline

PerformanceEntries are affected by backgrounded status
Nicolás: Wanted to chat about this, but no one from Apple is on the call.
… there’s some confusion about the use cases - some related to throttling and some related to visibility
… Need to be careful to support both of them
... e.g. paint metrics are really impacted by visibility, but other metrics might be impacted by throttling
... Wanted 3 types: visibility, network status (full vs. throttled), CPU usage
... Already exposing visibility, exposing the other 2 would make sense and wondered if people have concrete use cases beyond “taintedness”
... Also wanted to ask thoughts about API shape
... I was working on VisibiltyStateEntry which would not be extensible
... Should we have an API that covers all those 3 states, have them separate, what’s a good name, etc
Nic: Like the idea of getting more transparency into CPU and network usage
... Might be good to have it all under a single API.
Nicolás: Historically, the group pushed back on exposing throttling signals, but it’s become common in some cases, so even if we can’t define granularity of throttling, I think it makes sense to expose it to taint entries to some degree
Nic: If developer tools are open, that can also taint measurements
Nicolás: Good point
Yoav: Dev Tools open would in fact CPU throttling, it's not a different dimension, but a different reason
Nic: People can use devtools to do many things, pausing execution, etc. And we’d like to separate those experiences. So there could be other dimensions - code breakpointing
Timo: I am skeptical of the utility of this information. We currently use visibility state to drop entries. But over time, it’s part of a larger range of real world experiences. If throttling happens in the foreground, why should it be separated. That’s a real world experience.
… So interested in high level use cases. Would we ignore the data? How would that affect user experiences?
… also having memory distress, disk space distress is also a form of throttling
… It helps to get a stable baseline, but it also blinds us to non “standard” cases
Nic: I want to mark that data not to throw it, but to add it as a dimension
Michal: A stable baseline feels it’s interesting, but we shouldn’t throw out too much real world data
Michel: In Pinterest we’re collecting puppeteer and RUM data and synthetic tests are not enough to create a baseline.
... Plenty of regressions at RUM P90 from our deploys. So this API would be useful for us. We could ignore traces with throttling.
Nicolás: Ignoring throttling would make the data a bit more stable, but real life is still messy.
... Important to do analysis of data at a given point in time, and this can exclude cases you don’t have control over.
Steven: Interest from SalesForce as well
Michel: On top of devtools, there are scenarios where we have very small data, and want to filter open devtools. When the team debugs a page, we’re affecting our own data.
Timo: Supportive of a devtools signal. Visibility is different than the others, because users are likely not impacted (other than geeks looking at spinners)
Peter: Agree with Timo that exposing this can have mixed uses, so having a baseline of what throttling means would be helpful. We could have the impact of people discarding data that represents real users.