npm1
commented
4 years ago Hi, thanks for the feedback! Trying to get a better understanding of the problem here.
- Is there any other APIs where this is a problem, besides CLS? I think you might want FP/FCP/FID/LCP for large SPA navs but that would require a lot more complexity. This is something @mmocny et al are thinking about.
- For CLS specifically, why can't you just reuse the observer, since it's an SPA? If you keep the same observer and have a notion of when the SPA nav occurred, then you won't have dupes and you'll be able to compute CLS for each SPA nav manually. As 'performing an SPA' is not a standardized concept at the moment, this is not something the browser can do for you. But it's something that should work for CLS in particular.
dwsmart
wycats
yoavweiss
Hi,
There doesn't seem to be a clean method to 'reset / rerun' observers. This becomes relevant for SPA style sites. The PerformanceObserver sees just the one page, so when a user browsing the site goes to a new route, the figures from the observer are either for the initial route, or worse a combination of all the routes visited, rather than the route being browsed.
This is especially noticeable on something like CLS: User lands on example.com/foo The observers are initialised and data collected User clicks to example.com/foo/bar The observers are still running from example.com/foo, and also the new 'page' example.com/foo/bar
Something Cumulative Layout Shift would routes /foo & /foo/bar combined, leading to potentially wildy wrong metrics.
Some method to fire a re-initialization, or for this to happen on URL changing would make collection of these metrics much better on SPA sites, there's a huge amount of JavaScript SPAs, and SSR/Hydration frameworks like next.js, nuxt, sapper etc. this could benefit.