Re: ResourceTiming API & byte-size

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, 2 January 2013 23:24:18 UTC