Re: Support for page/resource size

+1

> On Jul 11, 2014, at 3:52 AM, Ritesh Maheshwari <riteshm@gmail.com> wrote:
> 
> Not to hijack the thread, but having a clear indication of whether the resource was fetched from browser cache or not would be really useful to have.
> 
> Chrome, e.g., currently would report non-zero values even when the resource is loaded from cache. I am assuming its reporting the time it took to load the resource from disk, but it doesn't help us trying to figure out, e.g., the browser cache-hit ratio of our apps.
> 
> Thanks,
> Ritesh
> 
> 
>> On Thu, Jul 10, 2014 at 8:03 PM, Ilya Grigorik <igrigorik@google.com> wrote:
>> 
>> 
>> 
>>> On Thu, Jul 10, 2014 at 5:54 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>> On 7/10/14, 5:03 PM, Philippe Le Hegaret wrote:
>>>>> On Wed, 2014-07-09 at 18:13 -0400, Anthony van der Hoorn wrote:
>>>> 
>>>>> 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.
>>>> 
>>>> We'd need feedback from implementers here to know if it's possible.
>>> 
>>> It depends on how "over the wire" size is defined.  Are we talking about the size of the HTTP "payload body" (in RFC 7231 terms; "message body" in RFC 2616 terms)?  Or are we talking the size of the actual HTTP messages?  Or are we talking about actual bytes on the wire, whatever wire means?
>>> 
>>> Specifically, given some data that is sent with Content-Encoding:gzip and Transfer-Encoding:chunked over an SSL connection, are we measuring the size of the HTTP "message body" (which in this case is gzipped, note), or the "payload body" (which has the extra bytes for the chunked encoding) or the actual HTTP messages (which include headers in addition to the data) or the size of the TCP packets (which include SSL overhead bits and the HTTP messages in encrypted form, plus the TCP handshake itself) or something else?
>>> 
>>> Basically, what is the goal of measuring this number?
>> 
>> Approaching this from the point of view of the developer who will be using this API: I expect this number to match whatever Content-Length reports in my developer tools. First and foremost it should provide me with an accurate measure of bytes transferred between client and server (i.e. compressed size if compression was applied), and if possible, the decoded size as well. The size of HTTP headers and other overhead is a separate story, and I'm not sure we need to get into that.
>>  
>>>> As far as I can tell, we discussed it back in 2011 [1], but didn't
>>>> follow on it either. At the time, the conclusion was that it was
>>>> possible to do it for same-origin resources at least. However, again,
>>>> the response may come from the cache.
>>> 
>>> Caches have to know the status code of the cached response, generally, so they can provide it to consumers.
>>> 
>>> More interesting is what the status code should be reported as if the browser did a conditional request and got back a 304.  Is the status code 304 or whatever the status code for the cached response is?
>> 
>> Once again, it should match what I see in developer tools: 304, and 0 for size (Chrome DevTools shows "from cache").
>> 
>> ig
>