Support for page/resource size

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