Intent to Implement & Ship Navigation Timing 2

122 views
Skip to first unread message

Shubhie Panicker

unread,
Nov 8, 2016, 1:33:11 PM11/8/16
to blink-dev, Yoav Weiss, kin...@chromium.org, Ilya Grigorik, Jian Sun
Contact emails

Spec

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

Link to entry on the feature dashboard

Requesting approval to ship?
Yes


Addy Osmani

unread,
Nov 10, 2016, 3:56:53 AM11/10/16
to blink-dev, yo...@yoav.ws, kin...@chromium.org, igri...@google.com, sun...@google.com
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

unread,
Nov 10, 2016, 9:23:43 AM11/10/16
to Addy Osmani, blink-dev, yo...@yoav.ws, kin...@chromium.org, igri...@google.com, sun...@google.com
I have manually added this to https://bit.ly/blinkintents as well.

Philip Jägenstedt

unread,
Nov 10, 2016, 11:24:24 AM11/10/16
to Addy Osmani, blink-dev, yo...@yoav.ws, kin...@chromium.org, igri...@google.com, sun...@google.com
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

unread,
Nov 11, 2016, 1:01:50 PM11/11/16
to Philip Jägenstedt, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
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.


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?

Philip Jägenstedt

unread,
Nov 11, 2016, 1:37:00 PM11/11/16
to Ilya Grigorik, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
Thanks Ilya, LGTM1.

Rick Byers

unread,
Nov 12, 2016, 7:16:58 PM11/12/16
to Philip Jägenstedt, Ilya Grigorik, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
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

unread,
Nov 14, 2016, 12:50:41 PM11/14/16
to Rick Byers, Philip Jägenstedt, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
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:

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

Rick Byers

unread,
Nov 14, 2016, 7:11:48 PM11/14/16
to Ilya Grigorik, Philip Jägenstedt, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
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

unread,
Nov 14, 2016, 7:16:21 PM11/14/16
to Rick Byers, Ilya Grigorik, Philip Jägenstedt, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
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

unread,
Feb 7, 2017, 2:27:40 PM2/7/17
to Chris Harrelson, Dru Knox, Rick Byers, Ilya Grigorik, Philip Jägenstedt, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
+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

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

unread,
Feb 7, 2017, 11:13:40 PM2/7/17
to Shubhie Panicker, Chris Harrelson, Dru Knox, Rick Byers, Ilya Grigorik, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
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

unread,
Feb 8, 2017, 7:15:47 PM2/8/17
to Philip Jägenstedt, Chris Harrelson, Dru Knox, Rick Byers, Ilya Grigorik, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
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

unread,
Feb 8, 2017, 8:41:41 PM2/8/17
to Shubhie Panicker, Chris Harrelson, Dru Knox, Rick Byers, Ilya Grigorik, Addy Osmani, blink-dev, Yoav Weiss, Kinuko Yasuda, Jian Sun
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.


Reply all
Reply to author
Forward
0 new messages