- From: Tony Gentilcore <tonyg@google.com>
- Date: Tue, 7 Jun 2011 12:27:02 +0100
- To: Bryan McQuade <bmcquade@google.com>
- Cc: James Robinson <jamesr@google.com>, Sigbjørn Vik <sigbjorn@opera.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Fri, Jun 3, 2011 at 4:29 PM, Bryan McQuade <bmcquade@google.com> wrote: > I'll just add to the thread that we should be very thoughtful about > how the measured times are spec'd, since some things performed by > browsers synchronously today may be performed asynchronously on a > background core in the future. For instance CSS parse time is today a > renderer-blocking event performed synchronously on the renderer core > in all browsers I'm aware of, but could be moved to a background core > in the future. In this case should CSS parse time be reported as the > amount of time spent on the background core, if none of that time was > spent blocking the renderer from making progress? Likewise IE9 parses > JS on a background core already. One could imaging decoding images on > a background core, etc. Good point. We ran across this in Navigation Timing for DNS resolution and connection establishment (which may be prefeteched). The decision was that the interface measures the time spent blocking on these operations, not the total time which they took. I suspect we'd follow this pattern for everything else.
Received on Tuesday, 7 June 2011 11:27:57 UTC