Open dwsmart opened 4 years ago
Hi, thanks for the feedback! Trying to get a better understanding of the problem here.
Hi @npm1
@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:
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!
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.