Re: ResourceTiming API & byte-size

(Sorry for double posting, premature "send" :) )
In yesterday's meeting I saw that byte-size was mentioned, and James is
opposed to adding that value:
"I feel that the interface should only include novel information that isn't
easily available today. The server serving the resources already knows the
size of the images."

Resource size is often *not* easily available to the server's logic (e.g.
mod_pagespeed automatically optimized images, and as far as the server
logic is concerned, it is a lower layer. Same for gzipped JS/CSS.)
Resource size information would enable:
* Creating full fledged waterfall charts in the browser
* Possibly estimating bandwidth [1] in JS, which can bring in much more
people to solve the bandwidth estimation problem.

I agree that at least in some cases these applications can be done by
having the server send over a manifest that includes a resource size map,
but that is not always the case, and would require an extra download, while
the browser already has that information.

Since we can agree that there's no security risk in adding that attribute
for same-origin hosts, I don't see why the fact that this information may
be available elsewhere prevents it from being added to the Resource Timing
API.

Thanks,
Yoav

[1] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0086.html


On Thu, Jan 31, 2013 at 9:27 AM, Yoav Weiss <yoav@yoav.ws> wrote:

> In yesterday's meeting I saw that byte-size was mentioned, and james is
> opposed to adding that value:
> "I feel that the interface should only include novel information that
> isn't easily available today. The server serving the resources already
> knows the size of the images."
>
> Image size is often *not* easily available to the server's logic (e.g.
> mod_pagespeed automatically optimized images, and as far as the server
> logic is concerned, it is a lower layer)
> Image size information would enable:
> * Creating full fledged waterfall charts in the browser
> * Possibly estimating bandwidth [1] in JS, which can bring in much more
> people to solve the bandwidth estimation problem.
>
> I agree that at least in some cases these applications can be done by
> having the server send over a manifest that includes a resource size map,
> but that is not always the case, a
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0086.html
>
>
> On Wed, Jan 30, 2013 at 2:11 AM, Arvind Jain <arvind@google.com> wrote:
>
>> I looked through the archives for previous discussion on this, and I
>> found only one thread:
>> http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/0059.html
>>
>> I suppose we could add the size field in next revision. We'll keep track
>> of this for Resource Timing v2.
>>
>>
>> On Tue, Jan 29, 2013 at 3:49 PM, Christian Biesinger <
>> cbiesinger@gmail.com> wrote:
>>
>>> Nvm, missed the "same origin" part of the question.
>>>
>>> -christian
>>>
>>>
>>> On Tue, Jan 29, 2013 at 3:48 PM, Christian Biesinger <
>>> cbiesinger@gmail.com> wrote:
>>>
>>>> Why do you say this poses no security risk? Byte size can reveal things
>>>> like "is user logged in to site X", which is not something we should expose.
>>>>
>>>> -christian
>>>>
>>>>
>>>> On Tue, Jan 29, 2013 at 3:39 PM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>>
>>>>> Since it poses no security risk and can be extremely useful, can byte
>>>>> size information be added to same origin resources in a future version of
>>>>> the Resource Timing API?
>>>>>
>>>>> Thanks,
>>>>> Yoav
>>>>>
>>>>>
>>>>> On Thu, Jan 3, 2013 at 12:23 AM, Jonas Sicking <jonas@sicking.cc>wrote:
>>>>>
>>>>>> On Wed, Jan 2, 2013 at 6:09 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>>>> >
>>>>>> > I'm wondering if there's any reason the resource's byte-size &
>>>>>> compressed
>>>>>> > byte-size were not added to the ResourceTiming API.
>>>>>> >
>>>>>> > The use cases I see for adding this information to the API would be:
>>>>>> > 1. Enabling Web apps access to the full information required to
>>>>>> create
>>>>>> > complete waterfall charts or HAR files that are equivalent to the
>>>>>> browser's
>>>>>> > own Web Inspector/developer tools. Current demos creating a
>>>>>> waterfall chart
>>>>>> > [1] or HAR files [2] either ignore the file size altogether, or use
>>>>>> the IE
>>>>>> > only property of "fileSize" on image resources.
>>>>>> > 2. Detecting compression issues using RUM scripts (text resources
>>>>>> that
>>>>>> > were not GZIPed, automated image compression regressions).
>>>>>> > 3. Enabling Web applications to get a notion of the average download
>>>>>> > bandwidth each resource had. Even though such a measurement may not
>>>>>> be
>>>>>> > accurate (because of slow-start, contention, packet losses,
>>>>>> different hosts
>>>>>> > per resource, etc), it may be useful information either for RUM or
>>>>>> for
>>>>>> > progressive enhancement purposes.
>>>>>>
>>>>>> The byte size and the compressed byte size can't be exposed for
>>>>>> cross-origin loads. Other than that I don't see any security issues
>>>>>> with this.
>>>>>>
>>>>>> / Jonas
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>