API for manually emitting soft-navigations?

[mxmul]

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 lets pages opt-out of these heuristics, and manually emit their own soft-navigation events instead?

[benmccann]

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

[lasseschou]

In my SPA application, the heuristics-based soft-navigation event is triggered very randomly. If I use mousedown to navigate (i know it's not best practice, but in some cases I prefer it), the event almost never happens. It would be super useful if I could override the automated event, and trigger a soft-navigation manually, or if there was another way to reset the LCP, INP and CLS values.

[tunetheweb]

If I use mousedown to navigate (i know it's not best practice, but in some cases I prefer it), the event almost never happens.

That's being tracked in #40

[lasseschou]

@tunetheweb I think #40 is more about mouseup, not mousedown.

In my SPA (implemented in vanilla JS), a mousedown event on a menu triggers a replacement of the inner content div with the new page (using appendChild). This is not giving soft-navigation events. Replacing with click handlers makes it more likely, but in ~30% of the cases, no soft-navigation, especially on the pages that don't have large SVG charts. When looking at the heuristics list, I'm not sure what I'm missing, but maybe the page transition is so fast that the contentful paints aren't being registered (do you even get contentful paint when the page content is just divs with text? Would be great if there were ways to debug this.

[tunetheweb]

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.

maybe the page transition is so fast that the contentful paints aren't being registered

That should not prevent the soft navigation event from being emitted.

Would be great if there were ways to debug this.

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).

[jasonwilliams]

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.

[mxmul]

My thinking was that PerformanceObserver could have an option that allows it to opt out of soft-navigation heuristics entirely, then the SPA could imperatively emit an event when they consider a page transition to have happened.

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();

[tunetheweb]

I am concerned that this could lead to variance in how the metrics are measured.

For example:

• SPA framework A calls markSoftNavigation at the start of the navigation, does all the work to fetch the next routes data, and then renders it.
• SPA framework B does all the work to fetch the next routes data, and then renders it, and then calls markSoftNavigation at the end of the navigation.

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.

[mxmul]

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?

[benmccann]

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.

[mmocny]

In the latest Chromium prototype, some of the "heuristics" for soft-navigations reporting is being decoupled from the fundamental features, such that it can become easier to build your own semantics.

• An "interaction-contentful-paint" entry tracks Interactions and reports on paints caused by it.
  • The idea is that this will (eventually) work for all interactions, not just those meeting the soft-nav heuristics
• Element timing is being expanded to support "container-timing", which can massively simplify manually measuring paint for large web components, page layouts, or even just the whole document.
• Existing performance timeline entries: resource timing, event timing, layout shifts... can also be segmented based on timestamps according to your own routing definitions.
• A "soft-navigation" entry just ties it all together and reports when all the default heuristics are met.

---

Thus, I don't think allowing an "explicit reset" is necessary or desirable. Instead, specific clients can start measurement whenever and however they want or use the defaults provided.

[mxmul]

Thanks for the update! That sounds perfect.

Assuming "interaction-contentful-paint" events continue to fire after LCP occurs, that should make it pretty simple for frameworks to measure LCP on soft navigations.