Add a landing attribute to PerformanceNavigationTiming

[yoavweiss]

This is a PR to demonstrate what defining a landing attribute could look like. This is not necessarily how we want the definition to land, as some concepts it relies on are not yet exported.

---

Preview | Diff

[yoavweiss]

@domenic - I'd love your advice on the best way to handle the currently unexported concepts (session history, and session history entry's document. Should they be exported from HTML? Should I PR a definition of a landing navigation in HTML and export only that definition? Something else?

[achristensen07]

If I understand this correctly, this is intended to return true if this is a same page "navigation", right? I'm confused by all this same page "navigation" measurement stuff. Don't web apps already have the ability to measure the performance of whatever they consider to be a same page "navigation"?

[yoavweiss]

If I understand this correctly, this is intended to return true if this is a same page "navigation", right?

Not really. The boolean returns true for "real" committed navigations (so MPA navigations, not SPA ones), when the navigation is the first one in the browsing session (so, essentially, the first one in its current tab from its origin).

This is useful for splitting MPA navigations to get better data on them, as well as to compare MPA and SPA data. For the latter case, one would focus on comparing MPA landing navigations with the SPA ones, as the non-landing MPA navigations are not really comparable.

Does this help clarify things?

Aside: writing the above made me realize that the current PR doesn't split the session on origin. I need to fix this...

[domenic]

Still on vacation, but @jakearchibald should probably get involved here as he's working on making "browsing session" and "origin of a session history entry" real concepts (whereas currently the spec for them is kinda broken).

[domenic]

Taking a look at this, I think probably it would be best to define a "landing document" in HTML and then you can return whether or not |document| is a landing document. Although normally I could go either way, given how gnarly the concepts involved are, keeping them in HTML where they can be revised as we continue to churn on the underlying model is probably the right idea.

[marcelduran]

Instead of a boolean landing, could a DOMHighResTimeStamp named landingTimeOrigin be more useful? It would contain the timeOrigin value from the very first lading navigation in a session.

This could allow a simple check whether the navigation is a landing: isLanding = performance.timeOrigin == performance.getEntriesByType('navigation')[0].landingTimeOrigin as well as potential session length (or time between navigations within the same session).

I believe I might be overlooking some potential privacy/security exposure. WDYT?

[andydavies]

@yoavweiss What benefits do this have over checking for referrer origin === current origin?

[jakearchibald]

@yoavweiss

The boolean returns true for "real" committed navigations (so MPA navigations, not SPA ones), when the navigation is the first one in the browsing session (so, essentially, the first one in its current tab from its origin).

I'm struggling with the MPA vs SPA thing… when would the first history entry of a tab be "SPA"?

[yoavweiss]

@marcelduran - what use case do you have in mind for a landing time stamp?

@andydavies - checking the referrer would give you different results. E.g. a navigation initiated in a new tab would be a "landing" navigation, but would have a referer value equal to its origin. Beyond that, referrer policy can also mean referer values are not sent at all.

@jakearchibald - This will not give us any ability to measure SPA "soft navigations", but it will enable us to know which MPA navigations could have been replaced by an SPA, compared to "landing" ones that are not replaceable (e.g. navigations initiated in a new tab).

[jakearchibald]

@yoavweiss

This will not give us any ability to measure SPA "soft navigations", but it will enable us to know which MPA navigations could have been replaced by an SPA, compared to "landing" ones that are not replaceable (e.g. navigations initiated in a new tab).

Ohh! Ok, as far as I know, a 'could have been an SPA navigation' cross-document navigation is:

• Was initiated by a document (not URL bar, bookmark click etc)
• Cross-document compared to the initiator
• Resulting origin, and any redirects, are the same origin as the initiator
• Targets the same frame as the initiator (but can be replace or add)

I'm not sure tagging a "landing" navigation gives you all that.

Also, what are you planning to do for traversals?

[marcelduran]

@yoavweiss

@marcelduran - what use case do you have in mind for a landing time stamp?

I don't have a particular real use case in mind. My motivation to suggest a timing (number) attribute instead of a boolean is based on my own prior request when working with @igrigorik to land a "fromNetwork" (or "isCached") boolean attribute to RT API. Back then all I cared was to know whether a resource was loaded from network or not (cache, etc). In the end, that attribute request ended up as transferSize which also included encodedBodySize and decodedBodySize. This trio leveraged multiple use cases instead of a single one.

Off the top of my head, a possible use case would be to use the landing timestamp as means to compute elapsed time in a session for any purpose, e.g.: (performance.timeOrigin + performance.now()) - performance.getEntriesByType('navigation')[0].landingTimeOrigin

That being said, my suggestion is an attempt to fulfill the current need but also allow future use cases to emerge.