Re: Support for page/resource size

Any thoughts on sending a checksum of the payload back as part of
ResourceTiming API?

Thanks,

Peter


On Fri, Jul 25, 2014 at 6:38 PM, <bizzbyster@gmail.com> wrote:

> Is there an issues database for this? That would be ideal for tracking
> these requests.
>
> I wonder if in addition to size we could also include the integrity
> metadata ( http://www.w3.org/TR/SRI/#dfn-integrity-metadata ) and
> cache-control headers. This information allows the web server to turn
> around and supply the integrity attribute to preload (subresource) resource
> hints via the LINK element when the cache-control headers indicate that the
> last seen object is still fresh. If we supply these "cache hints" back to a
> subsequent UA visiting the page, then the UA can avoid cache re-validation
> requests for objects that require revalidation but are actually still
> fresh. We can cut down on the 304 Not Modified traffic and reduce round
> trips.
>
> Thanks,
>
> Peter
>
> On Jul 22, 2014, at 10:20 AM, Anthony van der Hoorn <
> anthony.vanderhoorn@gmail.com> wrote:
>
> Just wanting to make sure that this doesn't get lost through the cracks...
> whats next to make sure this keeps moving on?
>
>
> On 16 July 2014 10:17, Reitbauer, Alois <Alois.Reitbauer@ruxit.com> wrote:
>
>>  We would have to check whether size over wire is available in all
>> browser implementations. Some use abstraction layers that do not allow to
>> get this information. Most likely the number to get is size of content when
>> browser gets it.
>>
>>  The discussion on error codes fits into navigation error logging:
>> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html
>>
>>  *// Alois*
>>
>>   From: Anthony van der Hoorn <anthony.vanderhoorn@gmail.com>
>> Date: Thursday 10 July 2014 00:13
>>
>> To: Philippe Le Hegaret <plh@w3.org>
>> Cc: Ilya Grigorik <igrigorik@google.com>, "aheady@microsoft.com" <
>> aheady@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
>> Subject: Support for page/resource size
>> Resent-From: "public-web-perf@w3.org" <public-web-perf@w3.org>
>> Resent-Date: Thursday 10 July 2014 00:14
>>
>>  Thanks for the response!
>>
>>  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".
>>
>>  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.
>>
>>  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.
>>
>>  Cheers
>> Anthony
>>
>> On Wednesday, July 9, 2014, Philippe Le Hegaret <plh@w3.org> wrote:
>>
>>> On Tue, 2014-07-08 at 18:43 -0400, Anthony van der Hoorn wrote:
>>> > Hi guys
>>> >
>>> > I'm new to the way that this group works, so if there is a better way
>>> to
>>> > approach this please let me know.
>>> >
>>> > I see that the v2 specs for NavigationTiming and ResourceTiming are in
>>> > progress and I'm interested in knowing whether there has been any
>>> > consideration to including the size of the page/resource in the API?
>>> >
>>> > I work on profiling/debugging tools, and the timing information is
>>> great,
>>> > but it would be amazing if we could start pulling together a profile
>>> of the
>>> > weight of the page.
>>> >
>>> > I guess other things come into play when starting to go in this
>>> direction
>>> > (like status codes, from cache, etc) but just wanted to know if anyone
>>> is
>>> > thinking about this.
>>>
>>> We considered it [1] but didn't make enough progress despite agreement.
>>>
>>> While trying to write a proposal, I realize that we have two different
>>> byte sizes that could be returned:
>>> 1. the byte size of the response
>>> 2. the byte size of the response's body
>>>
>>> The first one has the advantage that, for those who want to use
>>> heuristic to determine the bandwidth, having the size of the server
>>> response would be more accurate.
>>>
>>> Which one can we or do we provide?
>>>
>>> Philippe
>>>
>>>
>>>   The contents of this e-mail are intended for the named addressee
>> only. It contains information that may be confidential. Unless you are the
>> named addressee or an authorized designee, you may not copy or use it, or
>> disclose it to anyone else. If you received it in error please notify us
>> immediately and then destroy it. Compuware Austria GmbH (registration
>> number FN 91482h) is a company registered in Vienna whose registered office
>> is at 1120 Wien, Austria, Am Euro Platz 2 / Gebäude G.
>>
>
>
>