W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2014

Re: Support for page/resource size

From: Philippe Le Hegaret <plh@w3.org>
Date: Thu, 10 Jul 2014 17:03:33 -0400
Message-ID: <1405026213.2943.100.camel@chacal>
To: Anthony van der Hoorn <anthony.vanderhoorn@gmail.com>
Cc: Ilya Grigorik <igrigorik@google.com>, "aheady@microsoft.com" <aheady@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
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.


Received on Thursday, 10 July 2014 21:03:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:39 UTC