Re: add "networkDuration" to Resource Timing

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

Third-party support:
http://googledevelopers.blogspot.com/2013/12/measuring-network-performance-with.html
- I'd love to see a longer list. Reach out to your third party providers
and ask them to enable it.

"Unfortunately, duration is flawed since it includes the time the request
was blocked by another request or the rendering logic of the browser." --
rendering logic? The request dispatch *may* be delayed due to HoL blocking
on an http/1 connection, but rendering has no impact on this.

"Clearly the developers of the tools followed what seems logical from the
browser perspective; the Duration is the time from detecting the request to
finishing it. However, the end users of these tools often read it from
their perspective, i.e. how long it took for the URL to finish loading." -
you're using a narrow definition of "end user" as someone who is interested
in measuring their CDN performance... and DNS? Shouldn't you decouple those
two? What about measuring segmenting on cache perf time? End-to-end
protocol perf based on CDN support (in which case blocking should be
included)? I hope you see my point here... there isn't one, but many
different metrics here.

As we discussed earlier in this thread, "networkDuration" is misleading if
we include cache time, and if we don't then we're up against TAO
restrictions. The whole "add new attribute discussion" is a distraction:
there are many different metrics you should be measuring (and "duration" is
one of them) and UAs don't need to precompute all of these.. we simply need
to provide the raw data, which the current API already does..

----

(1) UA's should expose raw timing data - done.
(2) CDN's should provide easy "click here to add TAO header on proxied
requests".
(3) RUM solutions should gather raw data and allow developers to determine
what they care about.

ig


On Thu, Jan 8, 2015 at 8:37 AM, Steve Souders <steve@souders.org> wrote:

>  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> 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
>>
>>
>>
>
>