Re: Support for page/resource size

Another hole in the ResourceTiming API is that I can’t tell if objects requested via LINK rel=subresource were subsequently used by the page. ResourceTiming API treats preloaded resources the same as regular resources on that page. Also, there is no indicator that the initiator was a LINK tag. In summary, there is no way to figure out that preload hints were successfully used or not.

Does anyone else agree this needs to be addressed?

Thanks,

Peter

On Aug 8, 2014, at 5:47 PM, Peter Lepeska <bizzbyster@gmail.com> wrote:

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