W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2016

RE: Resource Timing Level 1 and beyond

From: Todd Reifsteck <toddreif@microsoft.com>
Date: Thu, 28 Apr 2016 00:22:39 +0000
To: Ilya Grigorik <igrigorik@google.com>, Philippe Le Hegaret <plh@w3.org>
CC: public-web-perf <public-web-perf@w3.org>
Message-ID: <BN3PR03MB2179E3B9D25B3FA07A142F75C2650@BN3PR03MB2179.namprd03.prod.outlook.com>
I’m in agreement with all of this.

Nicely done, Philippe!

-Todd

From: Ilya Grigorik [mailto:igrigorik@google.com]
Sent: Wednesday, April 27, 2016 3:43 PM
To: Philippe Le Hegaret <plh@w3.org>
Cc: public-web-perf <public-web-perf@w3.org>
Subject: Re: Resource Timing Level 1 and beyond

On Tue, Apr 26, 2016 at 7:52 AM, Philippe Le Hegaret <plh@w3.org<mailto:plh@w3.org>> wrote:
Following last week discussion, I added "Level 1" to Resource Timing with the following:
[[
This specification is ready for wide review, with the following features at risk for the first release:
*    Dependency with Performance Timeline 2, since performance observers are lacking implementations;
*    Dependency with High Resolution Time 2 and workers support, including workerStart, since we're still refining time origin;
*    nextHopProtocol, transferSize, encodedBodySize, and decodedBodySize, since we're currently lacking implementations.
]]

We also had secureConnectionStart marked as optional for a long time and recently changed it to mandatory. My proposal would be to also treat that change as an L2 feature. With these carveouts in place, I think we should have three existing implementations (Edge, FF, Chrome) of proposed L1. And once we land https://github.com/w3c/resource-timing/issues/46, we can (hopefully :)) confirm that.

Imho, the issue that affects the most implementations at the moment is
 https://github.com/w3c/resource-timing/issues/12

I'm proposing that we don't solve it for V1 but keep flagging it as an issue in the spec for Web developers to be aware of.

I agree. The spec did not indicate either way until we landed [1] and I think we can: (a) keep it as such for L1, (b) resolve it in L2. With that in mind, we would probably need to back out that commit for L1?

[1] https://github.com/w3c/resource-timing/pull/19/commits/0eb0f6997fc3f8a70a556212b45fa9ce5cfe7631


If we're ok with this, plan is to move a Level 1 version of the spec without the feature at risk and publish at the same time a Level 2 of spec as normal. Level 1 shouldn't impact editors, ongoing issues, or pull requests. The branch gh-pages will continue to hold v.next and https://www.w3.org/TR/resource-timing will continue to reflect it as a Working Draft. In other words, Level 1 is and should remain a side artifact. We do however have enough implementations of Level 1 to ship to Recommendation within 3/4 months.

sgtm. Much overdue, but better late than never! :)

ig
Received on Thursday, 28 April 2016 00:23:12 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 April 2016 00:23:13 UTC