- From: Hiroshi Kawada <kawada.hirosi@gmail.com>
- Date: Fri, 11 Jul 2014 00:12:40 +0900
- To: bizzbyster@gmail.com
- Cc: Anthony van der Hoorn <anthony.vanderhoorn@gmail.com>, Philippe Le Hegaret <plh@w3.org>, Ilya Grigorik <igrigorik@google.com>, "aheady@microsoft.com" <aheady@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <CAMK1dyMo_n6324-nSjLfuV7Ljdib3iVysm53x+6wg+H_aNfqWg@mail.gmail.com>
+1 It's good. I really want to know page/resources size. Does the user agent use the HTTP Header's content-length to that value? What's the value, when download is failed? It's really important. Hiroshi.K 2014-07-10 22:57 GMT+09:00 <bizzbyster@gmail.com>: > +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 >> >> >> >
Received on Friday, 11 July 2014 14:49:49 UTC