- From: Annie Sullivan <sullivan@google.com>
- Date: Wed, 1 Jun 2011 15:54:45 -0700
- To: Kyle Simpson <getify@gmail.com>
- Cc: Nic Jansma <Nic.Jansma@microsoft.com>, Zhiheng Wang <zhihengw@google.com>, public-web-perf@w3.org
>> 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