Comments (4)
Is the
visibilitychange
event really what we want to suggest here? And if so, could we add a sentence or two to explain what it's expected to capture, & perhaps to consider (and hopefully address) anticipated concerns about this event?
I think the recommendation is to use that event but only reporting when it changes to hidden. I don't think that results in firing way too often. It's the recommended way because it's the latest callback that reliably fires when the user leaves the page.
- Might not fire ever [to a first approximation], or at least not soon enough -- it looks like an arbitrarily large amount of time can pass before this event fires. e.g. Suppose a user opens your page, and they leave it open in its own browser-window -- then, this event will never fire, until they quit their browser, which they might never do. If the web developer is waiting on
visibilitychange
to send aggregated analytics, they may ~never get their report -- or maybe-worse: when they do get their report, its value may be the summation of several days' worth of layout shift metrics, which could produce a very large and ~meaningless metric. (For a largely static page, the metric may stabilize & stop changing & perhaps could be usefully reported after an arbitrary delay; but for any site with some dynamically-updating portion, e.g. Gmail/twitter, the metric would monotonically increase over time and could be arbitrarily large whenvisibilitychange
fires.)
This seems possible but extremely unlikely. Even if the user has a tab dedicated to the page (say, email), the page's process is not going to live forever. I think that the callback would be fired when the process dies. But it's certainly possible to have a timer in addition to the visibility change, so that the metric is guaranteed to be reported every X time.
@philipwalton any thoughts?
from layout-instability.
I think the recommendation is to use that event but only reporting when it changes to hidden. I don't think that results in firing way too often. It's the recommended way because it's the latest callback that reliably fires when the user leaves the page.
It fires (and reports as "hidden") when the user backgrounds the page, which could happen ~immediately and repeatedly -- that's my hypothetical "too-often" concern.
(Having said that: it seems reasonable to disregard perf measurements for backgrounded pages, because browsers may use different event-scheduling heuristics, and painting is free, etc. So from that sense, it does make sense to listen for this event and use it to reason about how you should feel about your performance metrics.)
the page's process is not going to live forever. I think that the callback would be fired when the process dies. But it's certainly possible to have a timer in addition to the visibility change, so that the metric is guaranteed to be reported every X time.
Stepping back a bit: my point here wasn't so much "the metrics might never come in", but rather "the thing that the sample code is reporting, cumulativeLayoutShiftScore
, is just a sum computed over an arbitrarily small or large amount of time. And it could vary by orders of magnitude depending on whether the user switches tabs (or closes the page) immediately vs. if the user leaves the page open for 5 minutes vs. if they leave the page open until its process dies. In a static page, it probably wouldn't vary, but in a dynamic webapp like Gmail where things are appearing, it would monotonically increase over time. Given this, it feels somewhat dubious that the reported cumulativeLayoutShiftScore
value would be useful in a real-life version of this usage example. (Maybe there are other implicitly-reported metrics that make it useful though?)
I feel like the usage-example would be more believable if the sample-code's updateCLS
function maintained a list of the reported LS values and their timestamps, perhaps - I would think that would be much more valuable for analytics to reason about ("Between time X and time Y, we had this layout shift, and then it stabilized"), rather than "while the page was open for all time, there was $arbitrary_sum
amount of layout shift.
from layout-instability.
I think the recommendation is to use that event but only reporting when it changes to hidden. I don't think that results in firing way too often. It's the recommended way because it's the latest callback that reliably fires when the user leaves the page.
It fires (and reports as "hidden") when the user backgrounds the page, which could happen ~immediately and repeatedly -- that's my hypothetical "too-often" concern.
Hmm yea, but my intuition is that this "too-often" is not a problem in practice?
Stepping back a bit: my point here wasn't so much "the metrics might never come in", but rather "the thing that the sample code is reporting,
cumulativeLayoutShiftScore
, is just a sum computed over an arbitrarily small or large amount of time. And it could vary by orders of magnitude depending on whether the user switches tabs (or closes the page) immediately vs. if the user leaves the page open for 5 minutes vs. if they leave the page open until its process dies. In a static page, it probably wouldn't vary, but in a dynamic webapp like Gmail where things are appearing, it would monotonically increase over time. Given this, it feels somewhat dubious that the reportedcumulativeLayoutShiftScore
value would be useful in a real-life version of this usage example. (Maybe there are other implicitly-reported metrics that make it useful though?)
Oh so I think you're making a point regarding normalization of the metric not being great at the moment. And I totally agree with that! The Chrome Speed Metrics team is thinking about this problem of how to improve CLS normalization so that it doesn't just penalize long-lived pages, and we're definitely open to ideas here!
I feel like the usage-example would be more believable if the sample-code's
updateCLS
function maintained a list of the reported LS values and their timestamps, perhaps - I would think that would be much more valuable for analytics to reason about ("Between time X and time Y, we had this layout shift, and then it stabilized"), rather than "while the page was open for all time, there was$arbitrary_sum
amount of layout shift.
That's a fair point, I think we can make tweak this example to report timestamps as well, so it's clear that the 'when' is also important. Does that sound good to you @skobes?
from layout-instability.
Oh so I think you're making a point regarding normalization of the metric not being great at the moment
Yes, roughly (or that's part of it). My point is that the layout shift information seems like something that a web developer would naturally want to reason about in a more fine-grained way -- e.g.:
- Hmm, our cumulative score is high and it spiked at time $Y; and in this case, it looks like that's when the $THIRD_PARTY_COMMENT_SYSTEM loaded. Let's look into that some more.
...vs: - Hmm, our cumulative score is high... but, it ticks up in a slow and steady fashion; this is consistent with [emails/tweets/what-have-you] appearing in our UI one by one over time, so probably nothing to worry about.
...vs: - Hmm, our cumulative scores are much lower today! But, they're from all from users who closed the page within 1 second, so that's not actually a good sign.
Basically: if the sample-code just sums up a score over an arbitrary & entirely-user-determined amount of time and reports that as the score, that feels like a waste (and a harder-to-imagine-as-useful usage) of a metric that's much more useful when reasoned about in a time/event-specific way.
from layout-instability.
Related Issues (20)
- CumulativeLayoutShift as WPT custom metric empty HOT 1
- Update CLS to window-based
- Specify layout shifts during drag HOT 2
- Explain expectations for content which shifts while fully obscured by other content (i.e. covered by a fixed position z-index overlay)
- Resolve confusion from equal previous/current rects
- Input Exclusion (lastInputTimestamp and hadRecentInput) should include certain interactions with Browser UI. HOT 1
- The definition of DCLS and CLS (non-normative) should mention ignoring shifts with hadRecentInput: True
- Broken references in Layout Instability API
- Clarify value of entry.name: empty string or "layout-shift"
- Layout shift reported without actual visual shifting for resized fixed iframe HOT 4
- exclude elements that transition from hidden to visible HOT 4
- CLS issue caused by FIXED position elements having z-index HOT 2
- Clarification about Hover causing layout shift HOT 2
- `content-visibility: auto;` makes CLS go bananas HOT 2
- Consider excluding user-scroll + scroll-anchor in the same frame from being penalized HOT 1
- What events trigger LayoutShift Performance Callback? HOT 2
- Starting point shift with countering transform change should be ignored HOT 1
- Change events should also trigger hadRecentInput
- ignore inline-direction shift in/out of view
- Case of sticky sidebars changing from absolute to fixed HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from layout-instability.