Re: Support for page/resource size

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
>