SvelteKit and Next.js have a concept of shallow routing to add a history entry when doing things like opening a modal. These aren't navigations, but would trigger the heuristic today. I really don't know how you can differentiate these cases without the framework's cooperation in tagging which actions are real soft navigations and which ones are shallow routings.
One idea might be to do something along the lines of changing the heuristic to detect that some percentage of the DOM changes. However, I can definitely think of cases where this would not work. E.g. if you're doing a real navigation from one product page to another, SvelteKit will surgically update the changed portions of the DOM without mounting an entirely new instance of the product page component. It's a real navigation where the picture and textual description will change, but the majority of DOM elements will remain untouched.
I'm a maintainer of SvelteKit and am extremely excited by the high-level goal of the soft navigation proposal. I'm happy to give feedback and support this within SvelteKit. SvelteKit apps are what we call "hybrid apps" where the initial page is rendered via SSR and subsequent pages rendered on the client like SPAs. INP heavily punishes the hybrid app model today even though it results in better perceived latency and a better user experience.
If there were an API to clarify which navigations were real navigations vs shallow navigations (e.g. potentially an extra option specified in the navigation API), we would happily adopt it. Even if this were a temporary API which would be clearly removed after some time, it could allow for measuring the effectiveness of any heuristic. Shallow routing is probably not a widely used API (especially for SvelteKit where it was very recently introduced though Next.js may have a bit more usage), so perhaps the decision in the end will be to write this problem off and accept some miscalculation in exchange for measuring soft navigations on a wider range of legacy applications. But if more preciseness were desired, there could be an API available on an opt-in basis to provide a more exact indication of soft navigations.
SvelteKit and Next.js have a concept of shallow routing to add a history entry when doing things like opening a modal. These aren't navigations, but would trigger the heuristic today. I really don't know how you can differentiate these cases without the framework's cooperation in tagging which actions are real soft navigations and which ones are shallow routings.
One idea might be to do something along the lines of changing the heuristic to detect that some percentage of the DOM changes. However, I can definitely think of cases where this would not work. E.g. if you're doing a real navigation from one product page to another, SvelteKit will surgically update the changed portions of the DOM without mounting an entirely new instance of the product page component. It's a real navigation where the picture and textual description will change, but the majority of DOM elements will remain untouched.
I'm a maintainer of SvelteKit and am extremely excited by the high-level goal of the soft navigation proposal. I'm happy to give feedback and support this within SvelteKit. SvelteKit apps are what we call "hybrid apps" where the initial page is rendered via SSR and subsequent pages rendered on the client like SPAs. INP heavily punishes the hybrid app model today even though it results in better perceived latency and a better user experience.
If there were an API to clarify which navigations were real navigations vs shallow navigations (e.g. potentially an extra option specified in the navigation API), we would happily adopt it. Even if this were a temporary API which would be clearly removed after some time, it could allow for measuring the effectiveness of any heuristic. Shallow routing is probably not a widely used API (especially for SvelteKit where it was very recently introduced though Next.js may have a bit more usage), so perhaps the decision in the end will be to write this problem off and accept some miscalculation in exchange for measuring soft navigations on a wider range of legacy applications. But if more preciseness were desired, there could be an API available on an opt-in basis to provide a more exact indication of soft navigations.