W3C home > Mailing lists > Public > public-web-perf@w3.org > June 2011

Re: Resource Timing - What's included

From: James Simonsen <simonjam@chromium.org>
Date: Thu, 9 Jun 2011 14:43:00 -0700
Message-ID: <BANLkTimwztvi5JEo2B+TanfosBDoOnfz6Q@mail.gmail.com>
To: Kyle Simpson <getify@gmail.com>
Cc: public-web-perf <public-web-perf@w3.org>
On Fri, Jun 3, 2011 at 8:18 AM, Kyle Simpson <getify@gmail.com> wrote:

> In the future, I think that same array of resources could potentially have
> new attributes added to each entry, such as their rendering timings
> (startRender, endRender, etc). But I'm not asking for that now. I am only
> asking that they be included in the array, as foundation for future
> improvements.
>

I fully agree that we need to have a foundation for exposing further
information, but I'd like to do it in a slightly different way.

I'm worried that trying to put all possible information about an element in
one place will lead to a lot of empty or unused information. For example,
script parsing time is relevant to inline scripts, but network timing is
not. So all those fields would be empty, but taking up space. Likewise, I
don't expect every developer to care about every bit of information on a
resource.

Instead, I'd like to solve the problem using composition. I would have one
API (Unified Timing) that can access different aspects about the element. In
my proposal, you could query PERF_SCRIPT to get an object containing parsing
time and PERF_RESOURCE to get an object containing network information. The
browser will only provide the ones that are populated. Developers would be
free to pick and choose which of those are relevant to them.

James
Received on Thursday, 9 June 2011 21:43:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 9 June 2011 21:43:36 GMT