Re: Resource Timing - What's included

>> 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 Thursday, 2 June 2011 16:19:27 UTC