Re: Resource Timing - What's included

I understand there's an insistence on the part of some members to keep 
"Resource Timing" to only talk about actual network timing. That's been made 
abundantly clear several times, and it doesn't need repeating again. In 
fact, I'd propose that if we end up sticking with that insistence, then 
"Resource Timing" is misnamed (it implies more generality than it affords, 
which is partly the confusion driving me to keep pushing the issue). We 
should rename it to "Resource Network Timing" if that's all it's ever going 
to serve.

But I am pushing back on that insistence to say that I think it's overly 
rigid and misses out on a potential benefit and simplicity.

I do not agree that having a second API with basically just an array of 
resources, along side *this* array of resources, is the best answer. The 
more moving parts we create, the harder it is for developers to grasp and 
understand. If one API can kill two birds with one stone, without 
significant complication (which I don't see any evidence of that in my 
request), then that's going to be easier for the community to grasp than 
having to learn two separate but very similar in functionality APIs.

In fact, the entries of the duplicate resource "requests" serves even more 
of a purpose than just the use-case I shared (finding positional occurences 
that affect rendering). It's useful information to analyze simply how many 
duplicates of a resource are on a page (memory consumption purposes, etc), 
which a simple scan of the array for entries with network timing of 0 can 
quite easily reveal.

Moreover, adding these "duplicate" entries to the array doesn't seem like it 
would create any onerous extra effort on those devs/tools that only want to 
look at unique requests, because it's trivial to filter such an array to 
exclude any entries with 0 for the timings. By contrast, a more limited 
array cannot in any useful way answer these extra use-cases.

So I don't see why extra functionality with minimal cost is a bad thing?

As I said on the phone call, there's enough overlap (they're both 
fundamentally arrays of the resource linkages from the markup, along with 
some associated timings of how those resources were handled) that I think it 
calls for expanding the scope (slightly) of the Resource Timing to include 
(for now) just a listing of of all resource "requests" (even those which are 
duplicates and don't create an actual network-layer connection), to serve 
these other use-cases.

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.


--Kyle



--------------------------------------------------
From: "Bryan McQuade" <bmcquade@google.com>
Sent: Friday, June 03, 2011 10:03 AM
To: "Annie Sullivan" <sullivan@google.com>
Cc: "Kyle Simpson" <getify@gmail.com>; "Nic Jansma" 
<Nic.Jansma@microsoft.com>; "Zhiheng Wang" <zhihengw@google.com>; 
<public-web-perf@w3.org>
Subject: Re: Resource Timing - What's included

> As Annie indicates, there is lots of rich and interesting information
> about how the renderer can be blocked. Renderer blocking is outside of
> the scope of the resource timing spec, which is focused instead on
> network layer information.
>
> I do believe that renderer-blocking-timing data is incredibly useful
> to web performance analysis, however it should not be part of this
> specification, as it is far more complex than just the single case of
> duplicate img tags (as Annie indicates).
>
> Consider looking at the speed tracer data dump format for encoding the
> kinds of information that can block the renderer:
> http://code.google.com/webtoolkit/speedtracer/data-dump-format.html
>
> We are going to be using this data format to import renderer-blocking
> information into Page Speed.
>
> Thanks,
> Bryan
>
>
>
>
> On Wed, Jun 1, 2011 at 6:54 PM, Annie Sullivan <sullivan@google.com> 
> wrote:
>>>> I understand your desire to include additional non-network-timing
>>>> information to the ResourceTiming interface, but that is not 
>>>> *currently*
>>>> within the scope of the spec.  My concerns about attempting to add
>>>> additional "how long did it take to load" information is that it
>>>> significantly explodes the scope of the spec and leads us into 
>>>> territory
>>>> that may be hard to define.
>>>
>>> Well, that type of information would certainly be useful, and if in the
>>> future we wanted to tackle adding it, then certainly it would warrant 
>>> having
>>> all those container entries in the array, right? I'd submit at least for
>>> consideration that changing in the future what elements are in the array 
>>> (as
>>> opposed to just what data properties are on each element) is a more 
>>> jarring
>>> change that could negatively impact tooling... so if such data is ever a
>>> future candidate for inclusion, perhaps having the placeholder elements 
>>> in
>>> the array isn't a terrible future-proofing step.
>>>
>>> BUT, that's not actually what I'm hoping for in this pass. What I was 
>>> hoping
>>> is, the list of external resources, as an ordered array, gives sort of a
>>> play-by-play of how resource loadings were encountered as a page was
>>> proceeding to parse and render. It's kinda like in baseball, how all 
>>> plays,
>>> errors, etc are all recorded, so that you can reconstruct a play-back of
>>> exactly how the game proceeded.
>>>
>>> Since things like a <link rel=stylesheet> placed strategically right 
>>> after a
>>> <script> (regardless of if that stylesheet resource is already loading 
>>> or
>>> not) affects how the timing of how the page was rendered (the <script> 
>>> will
>>> block in that case), then it makes sense to include it in the array at 
>>> that
>>> exact position, so that such positional traps can be detected. It 
>>> doesn't
>>> matter in this case that the network timing would be 0 for a duplicate
>>> reference to a stylesheet, what matters I that a reference to an 
>>> external
>>> stylesheet happened in a particular position as to affect the timing of 
>>> the
>>> processing of the page.
>>
>> I've been thinking about this a lot since the call this afternoon. I
>> looked up some of the other cases where a resource can be blocked. A
>> lot of the elements that can cause blocking do not attempt to download
>> anything from the network, so having this data won't help in many
>> cases. Some examples:
>>
>> Inline scripts can block downloads:
>> http://www.stevesouders.com/blog/2009/05/06/positioning-inline-scripts/
>> Conditional comments can change download behavior:
>> http://www.phpied.com/conditional-comments-block-downloads/
>>
>> So keeping the duplicate entry around doesn't always help with these
>> problems, and it can expose information about the user agent's caching
>> behavior, which I think we worry is a privacy issue and perhaps can
>> lead to fingerprinting.
>>
>> Tools like Google Page Speed already check for the case of stylesheets
>> after scripts: 
>> http://code.google.com/speed/page-speed/docs/rtt.html#PutStylesBeforeScripts
>> It seems like it would be pretty easy to use such tools to detect
>> blocking problems in automated tests, and get a more complete picture
>> of the blocking problems on a given page. I don't understand the
>> advantage of trying to do this debugging through the ResourceTiming
>> API.
>>
>> -Annie
>>
>>
>>
>

Received on Friday, 3 June 2011 15:18:45 UTC