performance.timing obsoleted: What should web developers use instead?

[sideshowbarker]

I’ve read https://github.com/w3c/performance-timeline/issues/68 and https://github.com/w3c/navigation-timing/commit/b9eee39 but can’t find anything in the spec or elsewhere that gives web developers guidance on what to use rather than performance.timing.

I updated the MDN docs at https://developer.mozilla.org/en-US/docs/Web/API/Performance/timing to recommend to web developers that they use PerformanceNavigationTiming instead.

Is that correct?

Regardless, whatever is actually recommended rather than performance.timing, could you please consider updating the spec to add some non-normative guidance for web developers about what they should be using instead?

https://github.com/mdn/sprints/issues/3093 is among the evidence the current state is confusing — especially confusing to web developers. Given the “required for browser-engine implementors but discouraged for web developers” nature of it, it’s gonna continue to cause some confusion. But having the spec give non-normative guidance about what to use instead might help mitigate some of the confusion.

[yoavweiss]

Generally, this seems like an issue on Navigation Timing, not Performance Timeline...

I’ve read #68 and w3c/navigation-timing@b9eee39 but can’t find anything in the spec or elsewhere that gives web developers guidance on what to use rather than performance.timing.

I updated the MDN docs at https://developer.mozilla.org/en-US/docs/Web/API/Performance/timing to recommend to web developers that they use PerformanceNavigationTiming instead.

Is that correct?

That is indeed correct, with the caveat that it's not yet supported in Safari.

Regardless, whatever is actually recommended rather than performance.timing, could you please consider updating the spec to add some non-normative guidance for web developers about what they should be using instead?

Isn't that covered by https://www.w3.org/TR/navigation-timing-2/#obsolete?

[npm1]

It seems the problem is MDN points at NavTiming1 when it should point to NavTiming2 at least (or latest draft - not sure what's generally used).

[sideshowbarker]

Generally, this seems like an issue on Navigation Timing, not Performance Timeline...

I’ve read #68 and w3c/navigation-timing@b9eee39 but can’t find anything in the spec or elsewhere that gives web developers guidance on what to use rather than performance.timing. I updated the MDN docs at https://developer.mozilla.org/en-US/docs/Web/API/Performance/timing to recommend to web developers that they use PerformanceNavigationTiming instead. Is that correct?

That is indeed correct, with the caveat that it's not yet supported in Safari.

OK — thanks for the confirmation

Regardless, whatever is actually recommended rather than performance.timing, could you please consider updating the spec to add some non-normative guidance for web developers about what they should be using instead?

Isn't that covered by https://www.w3.org/TR/navigation-timing-2/#obsolete?

Yes — dunno why I didn’t take note of the wording there before — it’s pretty clear. I guess I had just expected to find something specific at https://w3c.github.io/navigation-timing/#extensions-to-the-performance-interface but I suppose that’d just be redundant.

Anyway, I think the wording in that spec section is sufficient, so I’ll go ahead and close this as resolved.

[sideshowbarker]

It seems the problem is MDN points at NavTiming1 when it should point to NavTiming2 at least

Yes, thanks for catching that — I’ve now updated the spec URL in the MDN article