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:03:59 UTC