Re: Support for page/resource size

Not to be a broken record but to answer the question that Boris asked this
is what I would expect:

Request 1 - Successful request to the resource no cache hits anywhere
 - Status = 200
 - Cached = No
 - Original Over-the-wire (size) = 7.2 KB
 - Over-the-wire (size) = 7.2 KB
 - Actual (content) = 12.5 KB

Request 2 - Goes back to the server and gets a 304, no payload content is
returned
 - Status = 304
 - Cached = Server
 - Original Over-the-wire (size) = 7.2 KB
 - Over-the-wire (size) = 237 B
 - Actual (content) = 12.5 KB

Request 3 - Doesn't leave the browser
 - Status = 200
 - Cached = Client
 - Original Over-the-wire (size) = 7.2 KB
 - Over-the-wire (size) = 0 B
 - Actual (content) = 12.5 KB

With the above the data attributes would be described as follows:

 - Status - Status code that matches the request (same as status code in
Chrome DevTools network tab)
 - Cached - For cached results, explicit indicator of what type of cache
hit occurred
 - Original Over-the-wire (size) - Size is the number of bytes on the wire
of the original request (facilitating devs getting the Over-the-wire size
in cases where cache hits that don't leave the browser)
 - Over-the-wire (size) - Size is the number of bytes on the wire of this
request (allows one to determine the weight of the 304 response from the
server)
 - Actual (content) - Content is the actual size of the resource, matching
what Content-length would be

I think the different between size and content are described well in the
Chrome DevTools docs <https://developer.chrome.com/devtools/docs/network>:

- Size is the combined size of the response headers (usually a few hundred
bytes) plus the response body, as delivered by the server. Content is the
size of the resource's decoded content. If the resource was loaded from the
browser's cache rather than over the network, this field will contain the
text (from cache).
- Even though Size takes into account the response headers, it is typically
smaller than Content in cases where gzipping is used

I think the above covers the cases that Ritesh mentioned, as well as Ilya
point. As far as Boris's question about what specs cover the difference in
the way I've described Size vs Content, I'm not sure, but its the way I
think as a developer - maybe someone who knows the relevant specs more can
help with that if needed.

Lastly, one thing that I have been finding lacking from Resource
Timings/Timeline is a callback/event that one could tap to know when new
resources are loaded. At the moment, I am forced into what seem like hacks
to see when entries are added. It would be nice if there was a clear,
supported way to do this.

Cheers
Anthony

On 10 July 2014 17:38, Anthony van der Hoorn <anthony.vanderhoorn@gmail.com>
wrote:
>
> If it can be clearly indicated whether something has come from cache,
then I think the implementation could react accordingly. Take the following
requests:
>
> Request 1
>  - Status = 200
>  - Over-the-wire (size) = 7.2 KB
>  - Actual (content) = 12.5 KB
>
> Request 2
>  - Status = 304
>  - Over-the-wire (size) = 237 B
>  - Actual (content) = 12.5 KB
>
> Both requests are for the same resource, but the second one got a 304
from the server and hence the "Over-the-wire" is just the size of the
response saying its a 304 (pretty much just headers).
>
> This doesn't deal with the case where the browser reports a 200, but is
pulling it from the browser cache and hence never leaving the machine or if
we want to know what the original over-the-wire size was.
>
> Hence, what is probably needed is the following (note, actual names
probably need to be worked on):
>
> Request 1
>  - Status = 200
>  - Cached = No
>  - Original Over-the-wire (size) = 7.2 KB
>  - Over-the-wire (size) = 7.2 KB
>  - Actual (content) = 12.5 KB
>
> Request 2
>  - Status = 304
>  - Cached = Server
>  - Original Over-the-wire (size) = 7.2 KB
>  - Over-the-wire (size) = 237 B
>  - Actual (content) = 12.5 KB
>
> Request 3
>  - Status = 200
>  - Cached = Client
>  - Original Over-the-wire (size) = 7.2 KB
>  - Over-the-wire (size) = 0 B
>  - Actual (content) = 12.5 KB
>
> Additionally to this, there could be a collection of the headers that
matched the request/response, but I don't think that necessarily replaces
the above as the headers don't always indicate what the browser actually
did (i.e. did it actually get from private cache or not) or what the
"over-the-wire" size was vs the "Actual".
>
> Lastly, one thing that I have been finding lacking from Resource
Timings/Timeline is a callback/event that one could tap to know when new
resources are loaded. At the moment, I am forced into what seem like hacks
to see when entries are added. It would be nice if there was a clear,
supported way to do this.
>
> In terms of getting feedback from implementors to see what's possible,
what is needed for that (again I'm new to the process here). Additionally,
since this work has been discussed in the past but never really moved
forward (even with consensus) what is the best way to help it?
>
> Cheers
> Anthony
>
>
>
> On 10 July 2014 17:03, Philippe Le Hegaret <plh@w3.org> wrote:
>>
>> On Wed, 2014-07-09 at 18:13 -0400, Anthony van der Hoorn wrote:
>> > 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".
>>
>> An other drawback to the total request size is that, if the response
>> comes from the cache, the implementation may not have it.
>>
>> > 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.
>>
>> > 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.
>>
>> 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.
>>
>> Philippe
>>
>> [1]
>> http://lists.w3.org/Archives/Public/public-web-perf/2011Mar/0095.html
>>
>>
>