Intent to Implement & Ship Navigation Timing 2

[Shubhie Panicker]

Contact emails

pani...@chromium.org, sun...@chromium.org, igri...@chromium.org

Spec

https://www.w3.org/TR/navigation-timing-2/#introduction

Summary

Navigation Timing 2 (NT2) enables obtaining accurate timing data related to the navigation of the document.

Motivation

NT2 makes several improvements over previous API (Navigation Timing 1):

• Integration with new Performance Timeline interface (+ support for PerformanceObserver interface) allows developers to avoid polling the timeline to detect metrics and eliminating race conditions from shared buffer
• support for measuring service worker startup time, needed by PWAs
• addition of attributes: number of redirects, protocol information, support for pre-render 
• support for size information: transfer, encoded & decoded body size
• builds on Resource Timing - level 2
• new time origin using High Resolution time
• High resolution timestamps (consistency with other perf APIs and interfaces)

Interoperability and Compatibility Risk

None.

All vendors are in agreement and on board with the spec.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=611276

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5409443269312512

Requesting approval to ship?

Yes

[Addy Osmani]

This is incredibly exciting to see and it's equally great that all vendors appear to be on board with the current proposal. I'm particularly keen to get a better understanding of SW startup time in the wild.

[Philip Jägenstedt]

I have manually added this to https://bit.ly/blinkintents as well.

[Philip Jägenstedt]

Will this be behind a flag, or just landed and shipped? I was trying to figure out exactly what the new API surface is, and how this interacts with the redundant historical APIs.

Judging by the chromestatus entry, Edge has already shipped this. Looking at the spec and issues, I noticed the "back_forward" enum value, is it too late to fix that then?

[Ilya Grigorik]

Hi Philip. 

On Thu, Nov 10, 2016 at 8:24 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Will this be behind a flag, or just landed and shipped?

Landed and shipped.

 

I was trying to figure out exactly what the new API surface is, and how this interacts with the redundant historical APIs.

Summary of changes: https://www.w3.org/TR/navigation-timing-2/#h-sotd

Re, historical APIs: NT1 was the very first perf API and it predates performance timeline/performance observer. As a result, it exposes "performance.timing" object with epoch timestamps for the navigation (note: they're not high-res timestamps; they're not 'time origin' aware; etc). NT2 aligns itself with rest of the perf APIs and fixes all that: it's queued into perf timeline (e.g. performance.getEntriesByType('navigation') works; the record is also exposed to perf observer), it uses high res timestamps, etc. My hope is that eventually (realistically, this will take a while) we'll be able to deprecate NT1's performance.timing, but for time being we'll support both NT1 and NT2 interfaces -- same as Edge.

 

Judging by the chromestatus entry, Edge has already shipped this. Looking at the spec and issues, I noticed the "back_forward" enum value, is it too late to fix that then?

I believe so. Resolved in https://github.com/w3c/navigation-timing/issues/47.

[Philip Jägenstedt]

Thanks Ilya, LGTM1.

[Rick Byers]

Can you comment on how well our implementation will match the one already shipped in Edge?  I see the spec references these tests (yay), how complete would you say the test coverage is and to what extent is Edge passing it today?

If we're indeed matching Edge's already shipped implementation, then I agree the interop risk is very low and we should just go ahead.

[Ilya Grigorik]

AFAIK, the only missing bit in Edge is support for "secureConnectionStart", which is coming but taking a while due to layering with WinINet: https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?q=specName%3Anavigation-timing-2

The tests in web-plat repo are for NT1 and Todd is working on upstreaming their (Edge) tests for NT2:

https://github.com/w3c/navigation-timing/issues/39

The plan is to land those and make sure Chrome and Edge agree before we ship. 

[Rick Byers]

SGTM, thanks!  Note that the bar isn't necessarily 100% agreement, but we should consider the interop/compat risks of any differences.  I trust your judgement there, but let us know if you want our input.

LGTM2

[Chris Harrelson]

LGTM3

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Shubhie Panicker]

+Dru

Quick update here: Nav Timing 2 will ship in M57. Per public-web-perf discussion there is strong interest in addressing the following spec bugs in the branch:

1.Update name to URL instead of canned string "document" 

The reason is to be consistent with Resource Timing, and we won't be able to change the name once the API is in use.

This is a trivial change addressed with this CL and I will request merge shortly

2. data bias issues due to deferring reporting of nav timing 

The concern is that this limitation could limit adoption of the API, some developers have indicated that they won't be able to use the API until this issue is addressed. We are working on the fix, and would like to request merge (after the patches land and if all goes well).

Not sure what the process is exactly for requesting such fixes - does it require API owner approval? Feel free to point me to right documentation. 

Thanks.

[Philip Jägenstedt]

A small change to an existing feature doesn't need a new intent in general, unless perhaps it's risky or adds API surface. It's hard to draw the line, but I would personally want to err on the side of bypassing process, since adding paperwork for small changes probably reduces the amount of small but useful interop alignment work going on.

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Shubhie Panicker]

Thanks Philip!

The first change / fix was small and I've merged into M57 branch.

As for the second one - I'd say it's a medium sized change in terms of behavior change (it changes when and how the Nav Timing entry is queued) and implementation. It doesn't add any API surface. Should I seek approval on this thread or is there a separate process?

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

A change in timing to something that hasn't shipped yet is something I'd skip the process for, personally. But, if it makes a difference to how you would use the API in practice, then a PSA wouldn't hurt, just in case someone has insights or concerns.

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.