Re: add "networkDuration" to Resource Timing

Nic -

You can *not* calculate networkDuration from other attributes for 
*cross-origin* resources. That's why I'm suggesting adding this to 
PerformanceEntry (rather than PerformanceResourceTiming).

And as mentioned, about 50% of resources are cross-origin so it's 
important to provide a means for *accurate* download time measurements.

-Steve


On 11/25/14, 8:02 AM, Nic Jansma wrote:
> Steve,
>
> The only downside I see is that we're adding a new attribute that can 
> be entirely calculated via other attributes.
>
> One alternate (or additional thing) would be to highlight this point 
> in the description for "duration" in the spec.
> - Nic
> http://nicj.net/
> @NicJ
> On 11/25/2014 3:04 AM, Yoav Weiss wrote:
>>
>> On Tue, Nov 25, 2014 at 1:34 AM, Steve Souders <steve@souders.org 
>> <mailto:steve@souders.org>> wrote:
>>
>>     SHORT: I propose we add the "networkDuration" property to
>>     PerformanceEntry
>>     <http://www.w3.org/TR/performance-timeline/#performanceentry>
>>     objects.
>>
>>     LONG: A few weeks ago I discovered that "duration" includes
>>     blocking time, so "duration" is greater than the actual network
>>     time needed to download the resource. Since then I've been at
>>     Velocity and WebPerfDays where many people have shown their
>>     Resource Timing code. Everyone I spoke to (~5 different teams)
>>     assumed that "duration" was just the network time. When I explain
>>     that it also includes blocking they were surprised, admitted they
>>     hadn't known that, and agreed it is NOT the metric they were
>>     trying to capture.
>>
>>     I propose we add a new property to Resource Timing that reflects
>>     the time to actually load the resource excluding blocking time.
>>     I'm flexible about the name but for purposes of this discussion
>>     let's call it "networkDuration". The important piece of this
>>     proposal is that "networkDuration" should be available for all
>>     resources, similar to "duration". In other words, it should be
>>     available for same origin as well as cross origin resources as
>>     part of the PerformanceEntry
>>     <http://www.w3.org/TR/performance-timeline/#performanceentry>
>>     interface.
>>
>>     Same origin resources can calculate "networkDuration" as follows
>>     (assume "r" is a PerformanceResourceTiming
>>     <?ui=2&ik=b493d86064&view=att&th=149e4608a5dad0d6&attid=0.1.1&disp=emb&zw&atsh=0>
>>     object):
>>
>>         dns = r.domainLookupEnd - r.domainLookupStart;
>>         tcp = r.connectEnd - r.connectStart;        // includes ssl
>>     negotiation
>>         waiting = r.responseStart - r.requestStart; // aka "TTFB"
>>         content = r.responseEnd - r.responseStart;
>>         networkDuration = dns + tcp + waiting + content;
>>
>>     I've discussed this with a few people and the only concern I've
>>     heard is with regard to privacy along the lines of "if we exclude
>>     blocking we've added the ability to distinguish cache reads from
>>     network fetches". This isn't an issue for two reasons:
>>
>>      1. Even with the exclusion of blocking time, it's still possible
>>         for "networkDuration" to have a non-zero value for resources
>>         read from cache due to disk access time, etc. Therefore,
>>         excluding blocking time does not necessarily provide a clear
>>         means of determining resources read from cache.
>>      2. This concern assumes that adding "networkDuration" lessens
>>         privacy because removing blocking time provides additional
>>         information that is not available today. However, it's
>>         possible to exclude blocking time today by loading a
>>         cross-origin resource after window.onload, when there is no
>>         blocking contention.
>>
>>     Therefore, individuals who have JavaScript access to a page and
>>     can measure duration also have enough access to load resources
>>     after window.onload and can thus determine the duration excluding
>>     blocking time. Adding "networkDuration" does not give these
>>     individuals additional information beyond what is measurable today.
>>
>>     What "networkDuration" provides is additional information for the
>>     normal case of resources that are loaded as part of the main page
>>     when blocking contention may occur. This will give current web
>>     developers the metric they want for cross-origin resources, and
>>     will provide it more simply for same origin resources.
>>
>>
>> Assuming that the privacy concerns are in fact non-existent, a big +1.
>>
>