Re: add "networkDuration" to Resource Timing

+1

On Tue, Nov 25, 2014 at 12:31 PM, Nic Jansma <nic@nicj.net> wrote:

>  Good point!  Hadn't considered that, so yes I would agree it's a very
> valuable addition to consider.
>
> As far as what interface to put it on, I'm not sure networkDuration would
> make sense for UserTiming, for example.  While it could sit on
> PerformanceEntry and just be "0" for interfaces that aren't applicable, we
> could also create a PerformanceNetworkEntry interface (with
> networkDuration) that PerformanceResourceTiming inherits from, while
> PerformanceUserTiming only inherits from PerformanceEntry.
>
> That's all minor details though.  Really depends on the browser privacy
> teams OK'ing the addition.
>
> - Nichttp://nicj.net/
> @NicJ
>
> On 11/25/2014 12:16 PM, Steve Souders wrote:
>
> 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.
>
> - Nichttp://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> 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
>> <http://?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.
>
>
>
>
>