W3C home > Mailing lists > Public > public-web-perf@w3.org > January 2013

Re: ResourceTiming API & byte-size

From: Arvind Jain <arvind@google.com>
Date: Tue, 29 Jan 2013 17:11:07 -0800
Message-ID: <CAOYaDdMh_5CatUKLjCVOU1C45_A18qh-7r_ccBqexhJGQ=knbA@mail.gmail.com>
To: Christian Biesinger <cbiesinger@gmail.com>
Cc: Yoav Weiss <yoav@yoav.ws>, Jonas Sicking <jonas@sicking.cc>, public-web-perf <public-web-perf@w3.org>
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
>>>>
>>>
>>>
>>
>
Received on Wednesday, 30 January 2013 01:11:36 UTC

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