Re: Support for page/resource size

Just wanting to make sure that this doesn't get lost through the cracks...
whats next to make sure this keeps moving on?


On 16 July 2014 10:17, Reitbauer, Alois <Alois.Reitbauer@ruxit.com> wrote:

>  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>
> Date: Thursday 10 July 2014 00:13
>
> To: Philippe Le Hegaret <plh@w3.org>
> Cc: Ilya Grigorik <igrigorik@google.com>, "aheady@microsoft.com" <
> aheady@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
> Subject: Support for page/resource size
> Resent-From: "public-web-perf@w3.org" <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> 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.
>