- From: Ritesh Maheshwari <riteshm@gmail.com>
- Date: Fri, 11 Jul 2014 00:52:35 -0700
- To: Ilya Grigorik <igrigorik@google.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAD6QL2+Jf0_S8ji-cMs281vTLo6qY8GgqJhqugxedwMJB-faXQ@mail.gmail.com>
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 >
Received on Friday, 11 July 2014 14:49:50 UTC