What problem are you trying to solve?

See explainer.

When switching between pages, the navigation experience can be both abrupt and laggy when not instant.
It waits until commit before displaying any response, and then freezes (either the old frame or blank) until rendering is unblocked.

We want to allow authors to provide a better experience there, both reducing the "frozen" time and providing an exit/preview indication during exit (e.g. a skeleton);

What solutions exist today?

The developer can intercept the navigation (e.g. navigateEvent.intercept({precommitHandler}), and start a new navigation when they're ready.

However, this would create a slow end result as the cross-document navigation initiation is delayed.

Also developers can already show an animation when leaving the page, but it would be aborted mid-way in an abrupt way depending on commit timing.

How would you solve it?

1. Expose something along the lines of navigateEvent.deferCommit(promise) which would allow the old page to run whatever exit UI they want.

2. Expose something like navigateEvent.nextPageReadyToRender which is true on prerender/BFCache restore when the next page is not render-blocking. This would allow the old page to selectively decide whether to defer or let the presumably instant navigaiton continue.

Anything else?

1. This is different from A new API for work during unload #10997, where the "unload" actions are also valid for cross-origin navigations (e.g. an IndexedDB transaction). This is specific for in-app (same-origin) navigation customization.

2. In parallel, will pursue a way to do this declaratively in CSS, e.g. by allowing a CSS animation to declare that it is preferred for it to run until completion. This would allow this experience to be achieved declaratively, without having to manually clean up the state e.g. in the case of the navigation being aborted.