Re: Support for page/resource size

+1 the need for resource sizes. 

Beyond this, why not just include everything in the HAR specification( http://www.softwareishard.com/blog/har-12-spec/)  so we can generate waterfalls and debug performance issues with the current HAR-based toolset?

Thanks,

Peter

On Jul 9, 2014, at 6:13 PM, Anthony van der Hoorn <anthony.vanderhoorn@gmail.com> wrote:

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