Re: add "networkDuration" to Resource Timing

http://blog.catchpoint.com/2015/01/08/rum-resource-timing-api/

    /Relying on this [Resource Timing] data to report on third party
    performance is a huge red herring and can place the blame on
    providers who actually had little or no impact on perceived and
    total load times of the page. For this reason, we at Catchpoint have
    delayed inclusion of any features utilizing the Resource Timing API
    in Glimpse, our Real User Measurement Product./

:-(

-Steve

On 1/5/15 4:50 PM, Ilya Grigorik wrote:
> 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 
> <mailto: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 <mailto: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 <mailto: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
>
>