-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API for manually emitting soft-navigations? #13
Comments
There is a case where this could help: #39 Though rather than opting into a soft navigation, I wonder if the API should be opting out instead. E.g. it could be an option in the existing navigation API |
In my SPA application, the heuristics-based |
That's being tracked in #40 |
@tunetheweb I think #40 is more about In my SPA (implemented in vanilla JS), a |
I added #40 (comment) to say we need to potentially include "mouse down", "mouse up", "pointer up", "pointer down"m in #40. It's still part of that larger issue IMHO.
That should not prevent the
If you can share the site in a crbug.com/new this can be investigated there. This repo is more about questions on the spec (such as also including "mouse down") rather than bugs or implementation issues with your site or Chrome itself (though of course depending on the outcome of that, this may circle back to here if it requires spec changes). |
In Bloomberg we're predominantly a desktop app that embeds Chromium & V8, we don't change URLs but would like to measure CWVs for our own optimization opportunities, so we'd be interested in having the ability to manually reset too via an API. Some of our functions have states that would qualify for soft navigation (going from one part of the application to another) but we currently have no way of signaling this, nor can we reset our LCP metrics. https://developer.mozilla.org/en-US/docs/Web/API/Navigation/navigate seems to be the most likely place for a solution to live but it requires a URL, I don't know if there's some method to signal a soft navigation but decoupled from the URL history stack. |
My thinking was that Something like: new PerformanceObserver(updateLCP).observe({
type: 'largest-contentful-paint',
buffered: true,
includeSoftNavigationObservations: true,
enableSoftNavigationHeuristics: false // new option
});
...
// causes a 'soft-navigation' performance entry, allowing LCP to run again.
performance.markSoftNavigation(); |
I am concerned that this could lead to variance in how the metrics are measured. For example:
The definition of "LCP" (timed from when the navigation starts) would then be quite different. Alternatively framework A considers dialogs as a navigation (e.g. Twitter's "Post" button which changes the URL and opens a dialog), whereas framework B does not consider that a navigation since the original page is showing in the background. Again, this leads to differences in the number (and timing!) of navigations, and also therefore in the definition of "LCP" measured. The nice thing about a heuristic, assuming we can get one that is reasonably accurate, is it's the same for every SPA regardless of the tech it is built on - which is one of the big things we're trying to solve with this API. Similarly, LCP is intended to done at a broad scale based on heuristics without everyone having to implement element timing to say when the main content is done. Sites can of course emit their own performance marks or even use element timing, to improve on this locally (particularly when the LCP heuristic fails to measure what the site owner considers as "page loaded"), but the definition of LCP is more standardised and not possible to alter (leaving LCP hacks aside!). And on that note, SPA developers can emit their own soft navigation performance marks and loaded measurements right now without this API where it doesn't suit, but when it comes to the Core Web Vitals metrics it feels they should be measured similarly across all technologies. |
This is all fair, and it makes sense that we want heuristics that can be used to compare pages across the web. I don't want to be gaming the Core Web Vitals metrics as measured by a third-party. But when when collecting metrics about my own site for internal use, I'd love to be able to repurpose the browsers FCP / LCP / FID algorithms. I can emit a custom soft navigation performance mark today, but to measure the largest-paint since that mark I'd need to essentially polyfill LCP (e.g. using element timing) which is non-trivial. Is there a way to achieve both goals? |
Perhaps allowing frameworks to mark soft navigations as well as changes to history that should not be considered soft navigations would allow for detecting places where the heuristic is or isn't working well. It could be helpful both for supporting the effectiveness of the heuristic overall as well as identifying edge cases. I do agree it'd be problematic for Google to rely on these marks though, which would incentivize gaming them. |
This soft-navigation heuristics seem well thought-out and should cover most use-cases, but it may be hard to integrate with existing SPAs/frameworks that have their own notion of a soft navigation.
In our own SPAs, we have bespoke logic to determine whether a page transition has occurred. This is used to aggregate performance metrics, and other application-specific logging, so it's important that all of these metrics all have a consistent idea of when a page transition has occurred.
So we'd really like to be able to record LCP values (i.e. reset the LCP recorder) for each of these application-defined page transitions, without having to adopt the heuristic-based navigation events. Would it be possible to introduce an API that let's pages opt-out of these heuristics, and manually emit their own
soft-navigation
events instead?The text was updated successfully, but these errors were encountered: