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

Re: ResourceTiming API & byte-size

From: Yoav Weiss <yoav@yoav.ws>
Date: Wed, 30 Jan 2013 00:39:01 +0100
Message-ID: <CACj=BEgp2dX-UTj1fi+xfZZ2O63fSKV0AZUwwK6kjWqwvkx9rQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-web-perf@w3.org
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 Tuesday, 29 January 2013 23:39:28 UTC

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