Re: add "networkDuration" to Resource Timing

Understood, my personal objections to this proposal are:
1) I think we would have to exclude more than just blocking time.
2) I don't think selectively circumventing TAO is a viable strategy.. (1)
blocks this.
3) Independent of (2), I'm not convinced we should be defining more
duration~like metrics on perf entries, I think we should stick to
timestamps - i.e. give applications the raw data and let them define what
they care about. Case in point, the proposed metric is redundant in http/2
world. In fact, perhaps even "duration" was an unnecessary addition to the
spec, but that ship has sailed.

That said, those are own 2 cents, so take it for what its worth :)

ig

On Mon, Jan 5, 2015 at 11:40 AM, Steve Souders <steve@souders.org> wrote:

>  Hi, Ilya.
>
> The proposal in my initial email is still correct: expose
> "networkDuration" without TAO restrictions, where "networkDuration" does
> not include blocking time.
>
> The primary issue is that in the non-TAO scenario the only metric
> (duration) is misleading and we see that experienced developers are using
> it incorrectly. We need to get better insight for the non-TAO scenario.
>
> I tried to say that the name didn't matter, but I think it's causing
> confusion and derailing this thread. So let me propose a different name
> that might help: "loadtime".
>
> -Steve
>
>
> On 12/30/14 3:02 PM, Ilya Grigorik wrote:
>
>  On Tue, Dec 23, 2014 at 12:25 PM, Steve Souders <steve@souders.org>
>  wrote:
>
>> > I think the current definition of "duration" is correct
>> I've never questioned that the definition of "duration" is incorrect.
>> Instead, I'm suggesting that we add a new metric called something like
>> "networkDuration".
>
>
>  Seems like there are two separate threads here then:
> 1) proposal to add 'network duration', which excludes blocking and cache
> times... but should (for correctness) include redirect cases [a]? The
> latter gets real tricky with cross-origin redirects.
>  2) exposing 'network duration' without TAO restriction.
>
>  I have a feeling (2) would be a really hard sell as we'd be exposing an
> explicit cache vs. network fetch signal, and in effect circumvent current
> TAO restrictions. As for (1), it's a computable metric... as such, we're
> only talking about convenience - right?
>
>  ig
>
>  [a] http://lists.w3.org/Archives/Public/public-web-perf/2014Nov/0040.html
>
>
> On Tue, Dec 23, 2014 at 12:50 PM, Patrick Meenan <pmeenan@webpagetest.org>
> wrote:
>
>> Hmm, WebPageTest may report "something" in the blocked time but I think
>> it's always forced to -1 since I don't currently track it internally.  That
>> said, it's not that hard to add and I'll see if I can get it in before the
>> next HTTP Archive crawl.
>
>
> Thanks Pat! Really curious to see the results...
>
>  ig
>
>
>