Re: Support for page/resource size

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
>
>
>