- From: Nic Jansma <nic@nicj.net>
- Date: Wed, 23 Sep 2020 19:11:33 -0400
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
- Cc: Ilya Grigorik <igrigorik@google.com>, Yoav Weiss <yoavweiss@google.com>, Philippe Le Hegaret <plh@w3.org>
- Message-ID: <CAALun4sOWc9_5yLWbaJktDwSTajkgAYXrte8vrOnYF604gGpsg@mail.gmail.com>
Minutes
<https://docs.google.com/document/d/e/2PACX-1vQ-gcSRm3vkj90gM5xmleCrbZK0U7PVT5I670VTcZdUbYusAHfUPnWeQZJro7xMoes4xLn-hGvukzoP/pub>
from this meeting:
Participants
Nic Jansma, Yoav Weiss, Benjamin De Kosnik, Andrew Galloni, Carine Bournez,
Peter Perlepes, Nicolas Pena, Sean Feng, Chris Harrleson, Michal Mocny,
Phil Walton, Thomas Kelly, Michelle Vu, Dom Farolino
Next call September 24th @ 10PMMinutesLargest Contentful Paint
Call back to indicate that the observer is about to stop
<https://www.google.com/url?q=https://github.com/WICG/largest-contentful-paint/issues/43%23issuecomment-685905450&sa=D&ust=1600906260021000&usg=AOvVaw2fXTxrX1vgcqbxfEimgkbD>
(Nicolas)
- Final LCP
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1Ll8hMdr7SIqIKLWYf6Nw-5dJQha45BsNQWVHQDzAiSI/edit%23slide%3Did.p&sa=D&ust=1600906260022000&usg=AOvVaw0c6s5x70U-8czeMxSE1PBL>
slides
- Nicolas: 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?
- Nicolas: 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
- Nicolas: 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
- Nicolas: 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
- Nicolas: 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
- Nicolas: 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?
- Nicolas: 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?
- Nicolas: 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
- Nicolas: And we should consider better names
Preload
- preload #147 - "Delay the load event" should happen in HTML
<https://www.google.com/url?q=https://github.com/w3c/preload/issues/147&sa=D&ust=1600906260032000&usg=AOvVaw0iN9H3i5LbdD41cJPJgyUG>
- Nic: Should we discuss that at all?
- Yoav: Probably not
- preload #153 - Remove "Dependencies" section
<https://www.google.com/url?q=https://github.com/w3c/preload/issues/153&sa=D&ust=1600906260033000&usg=AOvVaw35bx_bb-eJ9ELsGqy2aRZD>
- 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
<https://www.google.com/url?q=https://github.com/w3c/preload/pull/149&sa=D&ust=1600906260034000&usg=AOvVaw3syEcehZ9jxEdJiFKAY6Gv>
- 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
<https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/105&sa=D&ust=1600906260036000&usg=AOvVaw266UrWRHq_h71_vEcXOmja>
- Nicolas: 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.
- Nicolas: 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
- Nicolas: 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.
- Nicolas: 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.
- Nichttp://nicj.net/
@NicJ
On Tue, Sep 8, 2020 at 10:54 AM Nic Jansma <nic@nicj.net> wrote:
> Hi everyone!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> for our next call (Thursday September 10 @ 10am PT / 1pm ET) we aim to have
> discussions on:
>
> - Largest Contentful Paint
> - Preload
> - Performance Timeline
>
> If you have any additional items you'd like to discuss, please add to the
> agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> .
>
> Join us <https://meet.google.com/agz-fbji-spp>!
>
> The meeting will be recorded and published online afterwards.
>
> See you soon!
>
> - Nic Jansma
> @nicj
>
>
Received on Wednesday, 23 September 2020 23:12:03 UTC