Re: add "networkDuration" to Resource Timing

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