performance-timeline

performance-timeline copied to clipboard

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.

Hi, thanks for the feedback! Trying to get a better understanding of the problem here.

1. 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.
2. 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.

Hi @npm1

1. Yes, CLS is perhaps a bad example as it's maybe the easiest to solve currently, but very much LCP, FID (especially with Google's web vitals push) but the other paint metrics too. Great to hear it's being though about.
2. True, but the timing perhaps get a little scruffy, and tracking this throughout an extensive session could become problematic. But I guess CLS does seem like one that's solvable 😀

@dwsmart I have the same problem and wrote up a gist ("In-App Navigation Metrics") to get a conversation going: https://gist.github.com/wycats/cb1ca235a2f789acc38b6b93b958f2c7

It's not feasible to expose every contentful paint. It would be possible to expose a contentful paint after a given point in time, and if the use case is for single page app navigations then it seems that the performance API should be related to an API that enables these kinds of navigations, not independent from it.

@wycats - thanks for the proposal!

This is a use case we discussed at length in the WG. I believe @mmocny is currently investigating this area, so may have more input on your proposal, and is likely to want your input on our current thinking in this space.

To expand a bit on what @npm1 said:

• Your proposal assumes that we can expose any arbitrary paint to web developers. Unfortunately, this is not something we can do for security reasons:
  • Visited links mean that exposing paints can also leak the user's history to any page.
  • Cross-origin credentialed resources can leak cross-origin user state, if they can be loaded in a way that result in paints (e.g. progressive images, scripts that touch the DOM, etc)
  • Potentially other security related reasons - we'll need to talk to security folks to make sure exposing arbitrary paints is ok, if we were to go down that route.
• At the same time, maybe there are mitigations to the above
  • We really should kill visitedness and be done with it.
  • Cross-origin isolated contexts can maybe enable us to expose arbitrary paints.
  • ???

On top of that, there's a current effort to revamp the history API (I'm aware of this proposal from @slightlyoff. @philipwalton also has thoughts on that front). It might be interesting to try and tie these 2 problems together, and come up with a History API of a shape that's more amenable to being monitored, and can expose reliable entries as a result.

For example, tying exposed paints to history changes (and rate limit how many paints we expose) might enable us to mitigate some of the security concerns with exposing arbitrary paints.

We discussed soft navigation reporting at TPAC. I'm hopeful we will soon have a path forward to report such navigations in ways that would enable us to correlate paints with those navigations, and enable us to surface paint timing events.

Very excited to see what comes from this! Thanks for putting in the work! 😃

Outlined the heuristic approach I have in mind. Comments would be appreciated!

As a heads up, Chrome is starting an origin trial with a proposed API that enables this: https://developer.chrome.com/blog/soft-navigations-experiment/

Would be awesome if y'all signed up, played with it (in production, if possible) and reported back feedback on the relevant proposal: https://github.com/WICG/soft-navigations

Great stuff @yoavweiss!

have set up the origin trial and am giving the soft-nav branch of the web-vitals library a try, looking good so far!