Add navigationId to PerformanceEntry #192

clelland · 2021-09-15T15:44:09Z

This adds the concept of a current navigation id to the global object, which starts at 0 and is incremented on every navigation event during a page's lifetime. This navigation id then gets exposed on PerformanceEntry objects, to allow those timeline entries to be segmented by user interaction.

Preview | Diff

clelland · 2021-09-15T20:17:52Z

This is probably okay for technical review at this point, but I wouldn't merge this until some other parts are done -- we should have bfcache navs trigger a kind of NavigationTiming entry, and we should have a way to observe "all navigations" as a meta-category.

index.html

yoavweiss

Looks good! a few nits

index.html

yoavweiss · 2021-09-20T06:57:26Z

OK, Now I remember... We have an ongoing discussion on w3c/page-visibility#51 on better ways to hook into the HTML algorithm here, so you probably want to follow the path outlined there, rather than link to that HTML algorithm directly. Happy to chat about this.

/cc @mmocny

clelland · 2021-09-23T20:24:36Z

OK, Now I remember... We have an ongoing discussion on w3c/page-visibility#51 on better ways to hook into the HTML algorithm here, so you probably want to follow the path outlined there, rather than link to that HTML algorithm directly. Happy to chat about this.

/cc @mmocny

That approach makes it look like that the global's navigation id should be entirely defined in HTML; there would seem to be little benefit to declaring it here and then making HTML call an algorithm here just to increment it.

clelland · 2021-10-01T19:00:15Z

Updated to move the navigation counter into HTML (Personal repo commit here) and use that instead of the session history document visibility change steps

Note that this will always be 0 for workers without a relevant document, and should start at 1 for documents with their first load.

yoavweiss · 2021-10-01T19:30:35Z

This LGTM. Let's land the HTML parts first though before landing this.

yoavweiss · 2022-09-20T09:34:11Z

Looking at the discussions on whatwg/html#7370, it seems like it'd be better if we could reach an agreement to land the HTML related processing there...

As currently (experimentally) implemented in SPA heuristics, the counter is not incremented on use of the Navigation API, but only when the heuristics are triggered. As SPA heuristics are not (yet) specified, maybe it's possible to convince the HTML folks to name this a navigation counter even if the only user is currently BFCache navigations?

Alternatively, we could name it whatever they are comfortable with, and rename it once SPA heuristics are mature enough to be specified?

paulirish · 2023-02-17T22:39:50Z

After seeing how navigationId works with bfcache/softnavs, I'm surprised by the 1-indexed appearance.

If relevantGlobal has an associated document:

Set newEntry's navigationId to the value of relevantGlobal's associated document's navigation id.

Otherwise, set newEntry's navigationId to 0.

What's the significance of a navId of 0?

Would that be like.. Network Error Logging reporting on a failed navigation? (Can't be, as NEL isn't a perftimeline concept?)
How would anything on the perf timeline get a navid of 0?

clelland · 2023-04-18T20:25:37Z

How would anything on the perf timeline get a navid of 0?

With the text as written, only events on a worker's timeline would have a navigationId of 0. A document's counter starts at 0, but is immediately incremented as the document loads.

That said, WICG/soft-navigations#12 is relevant to this discussion, and we should probably be replacing this with a less-counter-y mechanism in any case.

…n performance entries

clelland · 2023-07-27T18:39:52Z

Taking the feedback from WICG/soft-navigations#12 into account, I've updated this PR. navigationId is now a string rather than a counter, and all of the algorithms to manage it are here in Performance Timeline.

I expect that it doesn't need HTML integration support any more; I would instead change Navigation Timing to hook into this now, and call "Queue a navigation PerformanceEntry" rather than "Queue a PerformanceEntry".

clelland · 2023-08-28T14:02:29Z

Q: Should we export "most recent navigation" for situations where a timeline entry might be started before a navigation event, but queued after it finishes? I'm thinking about the case where a resource or event timing entry spans a soft-navigation, and we want it to be attributed to the navigation preceding the soft nav, even if it completes afterwards.

clelland · 2023-09-26T03:52:26Z

Ping @yoavweiss -- can you take a look?

yoavweiss

Apologies for the delay! This fell through the cracks..

yoavweiss · 2023-09-26T07:22:27Z

explainer.md

+When this API was originally designed, documents had a relatively simple lifecycle: they were
+loaded when the user navigated to them, and unloaded when the user navigated away, with the
+JavaScript environment being torn down at that time. Since then, the sitution has become more
+complex, with many browsers introducing a back-forwards-cache, with which a user can return


Nit: back-forward cache

yoavweiss · 2023-09-26T07:22:43Z

explainer.md

+loaded when the user navigated to them, and unloaded when the user navigated away, with the
+JavaScript environment being torn down at that time. Since then, the sitution has become more
+complex, with many browsers introducing a back-forwards-cache, with which a user can return
+a document wich they have previously navigated away from. The web has also seen a rise in


s/wich/which/

explainer.md

yoavweiss · 2023-09-26T07:24:27Z

explainer.md

+appears to the user as a navigation) can occur without the performance timeline being reset.
+In order to allow developers to reason about such events during the life of a page, some
+PerformanceEntry objects mark navigations, or navigation-like events. All PerformanceEntry
+objects include a navigation ID field, which links each PerformanceEntry to the most recent


s/links/ties/

yoavweiss · 2023-09-26T07:24:51Z

explainer.md

+In order to allow developers to reason about such events during the life of a page, some
+PerformanceEntry objects mark navigations, or navigation-like events. All PerformanceEntry
+objects include a navigation ID field, which links each PerformanceEntry to the most recent
+navigation entry which had occurred when the entry was generated.


s/when/before/ ?

yoavweiss · 2023-09-26T07:27:12Z

index.html

@@ -244,6 +247,12 @@ <h2><dfn>Performance Timeline</dfn></h2>
        </ul>
      </li>
    </ul>
+    <p>Each <a>Document</a> has:</p>
+    <ul>
+      <li>a <dfn>most recent navigation</dfn>, which is a <a>PerformanceEntry</a>,


yoavweiss · 2023-09-26T07:42:38Z

index.html

+        <li>Let <var>type</var> be <var>entry</var>'s <a>entryType</a>.</li>
+        <li>Let <var>startTime</var> be <var>entry</var>'s <a>startTime</a>.
+        </li>
+        <li>Return the [=string/concatenation=] of « <var>type</var>,


I know we initially talked about a UUID, but this may be equivalent. A few things that may hamper that:

Can we have multiple navigations per ms? Unlikely, but I'm not sure it's currently prohibited.

Having a predictable structure may cause developers to create weird reliances on the ID's structure (but I'm not sure that would be the case)
WDYT?

We can't have two navigations at the same monotonic time.

I think it's OK that people rely on this if it's well defined. It's only the URL and the start time which are anyway available.

Makes sense!

FWIW, when working on resource timing initiator (which uses a similar ID concept), we got feedback that it might be more ergonomic to use an object rather than a concatenated string.

Do we run into problems with object equality, if we use a structured object? Specifically, are there issues around key order or numeric precision, or just the fact that object equality is often conflated with object identity?

Discussed at the WG; there probably are issues with identity/equality here, and a string has better comparison behaviour, as long as we ensure it is unique.
Sticking with - will allow this pattern to be reused for other cases where we want to refer to timeline entries as well.

yoavweiss · 2023-09-26T07:43:54Z

index.html

+        <li>Let <var>startTime</var> be <var>entry</var>'s <a>startTime</a>.
+        </li>
+        <li>Return the [=string/concatenation=] of « <var>type</var>,
+        <var>time</var> » using U+002D HYPHEN-MINUS.</li>


concatenation is defined for a list of strings, so I think you need to convert the timestamp to a string first.

yoavweiss · 2023-09-26T07:45:31Z

index.html

          <var>name</var> set to the method input <code>name</code> parameter, and
          <var>type</var> set to <code>null</code> if optional `entryType` is omitted,
          or set to the method's input <code>type</code> parameter otherwise.</p>
        </section>
+        <section>
+          <h2><dfn>getEntriesByNavigationId()</dfn> method</h2>


Did we discuss creation of a dedicated filter, compared to applying a JS filter on getEntries()? I'm guessing this would have performance benefits, but it's worthwhile to articulate the reasoning (maybe in the explainer)

Krinkle · 2023-09-28T18:02:40Z

RE: Today's W3C WebPerf presentation by @clelland in which we saw an integer ("counter") and string idenitifier ({type}-{startTime}) proposed as value for the navigationId.

I believe startTime could theoretically clash in some unlikely pathalogical scenario where time doesn't move or things happen very fast during recovery from a blockage of sorts. Assuming navigationId has to be unique within a realm, and startTime isn't, does that mean the number would be altered or extended in some way in practice in the event of a conflict? If so, it might be worth reserving something in the format so that consumers won't be caught in surprise when an entry's navigationId varies notably from the assumed string format. For example {type}-{startTime}-{number} where the latter would be 0 most cases but mediate would-be conflicts.

It's not clear what value startTime adds in that case, since it doesn't aid sorting (we'd need {startTime}-{type} instead of {type}-{startTime} to aid sorting), and is presumably not meant for machine-readable consumption either (the entry objects have .startTime for that).

So perhaps {type}-{number} would be simpler if we only want to reflect that it's a blackbox string that is neither an array index nor key for approx time order. Or a step further, and plain {number}, as blackbox integer, in which case we're back to a setTimeout-like integer/counter 😁

noamr · 2023-09-28T19:16:24Z

RE: Today's W3C WebPerf presentation by @clelland in which we saw an integer ("counter") and string idenitifier ({type}-{startTime}) proposed as value for the navigationId.

I believe startTime could theoretically clash in some unlikely pathalogical scenario where time doesn't move or things happen very fast during recovery from a blockage of sorts.

It's monotonic time, so it should be unique % coarsening.

* Fix typos * Remove getEntriesByNavigationId() * Convert timestamps to strings for concatenation

clelland · 2023-10-05T19:16:35Z

Thinking more about this issue this morning, @yoavweiss, @yashjoshi-dotcom and I came to the conclusion that {type}-{startTime} probably won't work as a general id mechanism for performance entries. We can't use it for resource timing or event timing, or even paint timing, as it's almost certain to generate collisions.

However, there is a useful mechanism in event timing already, for generating interaction ids. I think we can reuse that logic here, to assign an integer id to every entry, and then navigationId will just use the id for the relevant navigation entry.

It's monotonically increasing, but doesn't have a predictable start or increment¹ so you'd have to go out of your way to try to depend on the exact sequence of values. (And it was the potential for those dependencies which was the reason we didn't want a simple counter.)

Should the increment be random each time? Or is a small consistent step better? That's a topic for bikeshedding ↩

yoavweiss

LGTM % comment

Maybe you can do a 5 minute presentation on tomorrow's call to update folks on where we landed?

yoavweiss · 2023-10-11T15:14:28Z

explainer.md

@@ -59,6 +59,7 @@ The entry has the following attributes:
 * `entryType`: a string representing the type of performance data being exposed. It is also used to filter entries in the `getEntriesByType()` method and in the `PerformanceObserver`.
 * `startTime`: a timestamp representing the starting point for the performance data being recorded. The semantics of this attribute depend on the `entryType`.
 * `duration`: a time duration representing the duration of the performance data being recorded. The semantics of this one also depend on the `entryType`.
+* `navigationId`: a string identifying the `PerformanceEntry` object corresponding to the last navigation or navigation-like event that had occurred in the document at the time that this `PerformanceEntry` object was recorded.


explainer.md

Add navigationId to PerformanceEntry

db40939

npm1 reviewed Sep 15, 2021

View reviewed changes

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

yoavweiss reviewed Sep 16, 2021

View reviewed changes

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

Move navigation counter to HTML

3248985

clelland mentioned this pull request Oct 29, 2021

API shape for monitoring new navigation-like entries such as App History, BFCache, etc #182

Open

Merge branch 'gh-pages' into add-navigation-id

cb8dd26

clelland mentioned this pull request Nov 25, 2021

Add a navigation counter to Documents whatwg/html#7370

Closed

3 tasks

clelland added 3 commits November 26, 2021 12:36

Add proposed update to explainer text

6e5497e

Merge branch 'gh-pages' into add-navigation-id

3adcc6a

Add HTML concepts into this doc until they are merged there.

564c3cb

clelland added 2 commits June 9, 2023 13:48

Merge branch 'gh-pages' into add-navigation-id

ec0e067

Change navigationId to a string, and add algorithm to queue navigatio…

1497e2a

…n performance entries

This was referenced Jul 27, 2023

Soft Navigations w3ctag/design-reviews#879

Closed

Soft Navigations WebKit/standards-positions#235

Open

clelland requested a review from yoavweiss August 24, 2023 13:28

yoavweiss reviewed Sep 26, 2023

View reviewed changes

Addressing review comments

8e34f8f

* Fix typos * Remove getEntriesByNavigationId() * Convert timestamps to strings for concatenation

Introduce an id, and change navigationId to point to it.

771922d

yoavweiss approved these changes Oct 11, 2023

View reviewed changes

Update explainer, too

1550c7d

clelland merged commit f6a67dc into w3c:gh-pages Oct 11, 2023
2 checks passed

clelland deleted the add-navigation-id branch October 11, 2023 15:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add navigationId to PerformanceEntry #192

Add navigationId to PerformanceEntry #192

clelland commented Sep 15, 2021 •

edited by pr-preview bot

clelland commented Sep 15, 2021

yoavweiss left a comment

yoavweiss commented Sep 20, 2021

clelland commented Sep 23, 2021

clelland commented Oct 1, 2021

yoavweiss commented Oct 1, 2021

yoavweiss commented Sep 20, 2022

paulirish commented Feb 17, 2023 •

edited

clelland commented Apr 18, 2023

clelland commented Jul 27, 2023

clelland commented Aug 28, 2023

clelland commented Sep 26, 2023

yoavweiss left a comment

yoavweiss Sep 26, 2023

yoavweiss Sep 26, 2023

yoavweiss Sep 26, 2023

yoavweiss Sep 26, 2023

yoavweiss Sep 26, 2023

yoavweiss Sep 26, 2023

noamr Sep 26, 2023

yoavweiss Sep 26, 2023

clelland Sep 28, 2023

clelland Oct 4, 2023

yoavweiss Sep 26, 2023

yoavweiss Sep 26, 2023

Krinkle commented Sep 28, 2023

noamr commented Sep 28, 2023

clelland commented Oct 5, 2023

yoavweiss left a comment

yoavweiss Oct 11, 2023

Add navigationId to PerformanceEntry #192

Add navigationId to PerformanceEntry #192

Conversation

clelland commented Sep 15, 2021 • edited by pr-preview bot

clelland commented Sep 15, 2021

yoavweiss left a comment

Choose a reason for hiding this comment

yoavweiss commented Sep 20, 2021

clelland commented Sep 23, 2021

clelland commented Oct 1, 2021

yoavweiss commented Oct 1, 2021

yoavweiss commented Sep 20, 2022

paulirish commented Feb 17, 2023 • edited

clelland commented Apr 18, 2023

clelland commented Jul 27, 2023

clelland commented Aug 28, 2023

clelland commented Sep 26, 2023

yoavweiss left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Krinkle commented Sep 28, 2023

noamr commented Sep 28, 2023

clelland commented Oct 5, 2023

Footnotes

yoavweiss left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clelland commented Sep 15, 2021 •

edited by pr-preview bot

paulirish commented Feb 17, 2023 •

edited