NavigationTimingType enum need updates as HTML spec changed

[Elchi3]

https://w3c.github.io/navigation-timing/#sec-performance-navigation-types references the HTML spec for history handling behavior, however the HTML spec was updated so links to it don't work anymore.

Now: https://html.spec.whatwg.org/multipage/browsing-the-web.html#history-handling-behavior
Previously: https://html.spec.whatwg.org/commit-snapshots/f1db8a07e23c0ccb73ed2f596041846f43926a85/#history-handling-behavior

[Krinkle]

From https://w3c.github.io/navigation-timing/#sec-performance-navigation-types:

Navigation where the history handling behavior is set to "entry update".

The "history handling behavior" link still resolves but indeed now only covers push and replace. The
"entry update" link has become a dead-end.

[yoavweiss]

Also, the enum refers to the prerender definition in ResourceHints which is being discontinued. ^^ @jeremyroman @noamr

[jeremyroman]

@nhiroki @domenic currently in Chromium and in the WICG/nav-speculation step AFAICT the new prerendering stuff does not currently use the prerender type PerformanceNavigationType. Perhaps it should.

Regardless I'm not sure what that means for w3c/navigation-timing; maybe it should leave it open to other specifications, as long as prerendering isn't yet merged into WHATWG HTML?

[domenic]

I don't know enough about what people use PerformanceNavigationType for to know how its semantics might change.

Since prerenders could in theory be used to fulfill back/forward and reload navigations, it feels orthogonal to me. But I'm not sure.

I agree w3c/navigation-timing should remove the prerender type. If we want to add it in to WICG/nav-speculation as a monkeypatch, we can.

[jeremyroman]

Since prerenders could in theory be used to fulfill back/forward and reload navigations, it feels orthogonal to me. But I'm not sure.

But this isn't known at the time a prerender starts, which is when the PerformanceNavigationTiming entry first becomes available, right?

[tunetheweb]

I don't know enough about what people use PerformanceNavigationType for to know how its semantics might change.

I mentioned this in my post: https://developer.chrome.com/blog/prerender-pages/#:~:text=At%20present%20the%20PerformanceNavigationTiming.type%20is%20not%20using%20the%20prerender%20value%2C%20that%20was%20for%20the%20older%2C%20original%20%3Clink%20rel%3D%22prerender%22...%3E%20navigation%20type.

So I think this is useful as I mentioned in #184 . Otherwise we end up repeating a lot of boiler plate code like this https://github.com/GoogleChrome/web-vitals/blob/39f178242afbb96dca3d48b216d60e7cd4cfa633/src/lib/initMetric.ts#L26-L34 which as well as being repetitive, depends on a degree of knowledge of all the non-standard types and how to define them all. Much easier to just get it from the API as you would for any other navigation time.

This because one of the main uses (to me at least) is to be able to understand how users use your website (are they mostly navigating? Or going back and forward a lot? Do they get use of the bfcache? Are we getting the expected number of prerender of bfcache hits? Can we drive those up more? Are certain pages failing to use those navigation types? Or are certain pages being reloaded a lot (perhaps due to a problem). As such I measure the (extended) navigation type in analytics. This also allows different performance characteristics to be measures (How are my Core Web Vitals per page type? Are prerendered pages typically faster than plain navigations? ..etc.).

Of course it's not perfect (navigations could be cold navs, or fully warmed navs with all the resources in the HTTP Cache, or some level in between - which will impact the performance characteristics), but it's still useful IMHO.

Since prerenders could in theory be used to fulfill back/forward and reload navigations, it feels orthogonal to me. But I'm not sure.

That's true, but I'm less worried about that since I think there's already overlap and ambiguity. For example a "navigate" navigation to a page that was recently visited is basically the same as a back-forward navigation as both will use the HTTP Cache (this is assuming no bfcache though I argue, for the reasons given above, in #184 that this should be a navigation type too). Knowing a page was prerendered is more useful to me than knowing it was a prerender for a back/forward or reload navigation.

I guess what was the original thinking of that enum? And of having prerender in there?
And what are other people using this for? When we discussed #184 on the WebPerfWG (minutes there seemed some support and no disagreement for it.

[annevk]

The "prerender" enum value is also dead code in WebKit. Was this ever tested?