Re: add "networkDuration" to Resource Timing

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