Re: Support for page/resource size

We would have to check whether size over wire is available in all browser implementations. Some use abstraction layers that do not allow to get this information. Most likely the number to get is size of content when browser gets it.

The discussion on error codes fits into navigation error logging: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html

// Alois

From: Anthony van der Hoorn <anthony.vanderhoorn@gmail.com<mailto:anthony.vanderhoorn@gmail.com>>
Date: Thursday 10 July 2014 00:13
To: Philippe Le Hegaret <plh@w3.org<mailto:plh@w3.org>>
Cc: Ilya Grigorik <igrigorik@google.com<mailto:igrigorik@google.com>>, "aheady@microsoft.com<mailto:aheady@microsoft.com>" <aheady@microsoft.com<mailto:aheady@microsoft.com>>, "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Support for page/resource size
Resent-From: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Thursday 10 July 2014 00:14

Thanks for the response!

To me, I can see value in both - would it be that much of a "cost" to pay if both are captured and made available (as it would be handy to know both and even be able to derive the header size)? But, personally, if I was pushed, I would probably go with total request size. I think this would fall inline with expectations - as I think that's what most dev tools show and tells me the true size of the request if I care about the network "cost".

Additionally (and I say this hoping it's not pushing my luck), I would like to know the "over-the-wire" size vs the "actual" size (chrome dev tools calls this "content" vs "size"). That way we can start flagging requests that aren't compressed, see bandwidth cost of payload, etc.

Lastly (and I think this might be really pushing things), I would like to know the status code associated with the request. This lets us flag resources that aren't cached, have errors, etc.

Cheers
Anthony

On Wednesday, July 9, 2014, Philippe Le Hegaret <plh@w3.org<javascript:_e(%7B%7D,'cvml','plh@w3.org');>> wrote:
On Tue, 2014-07-08 at 18:43 -0400, Anthony van der Hoorn wrote:
> Hi guys
>
> I'm new to the way that this group works, so if there is a better way to
> approach this please let me know.
>
> I see that the v2 specs for NavigationTiming and ResourceTiming are in
> progress and I'm interested in knowing whether there has been any
> consideration to including the size of the page/resource in the API?
>
> I work on profiling/debugging tools, and the timing information is great,
> but it would be amazing if we could start pulling together a profile of the
> weight of the page.
>
> I guess other things come into play when starting to go in this direction
> (like status codes, from cache, etc) but just wanted to know if anyone is
> thinking about this.

We considered it [1] but didn't make enough progress despite agreement.

While trying to write a proposal, I realize that we have two different
byte sizes that could be returned:
1. the byte size of the response
2. the byte size of the response's body

The first one has the advantage that, for those who want to use
heuristic to determine the bandwidth, having the size of the server
response would be more accurate.

Which one can we or do we provide?

Philippe


The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Geb?ude G.