Re: Proposal for JavaScript Timing Extension to the Performance Timeline

Is the idea to only do this when scripts are inserted into the page? That
seems to be what the examples are showing. For many scripts, that'll just
end up being parsing time.

In general, I'd like to limit the amount of data in the timeline.
Developers should specifically ask for something to be recorded. We want to
discourage developers from trying to collect mountains of debug timing data
on users' machines. I think flipping one switch to get all the script data
is too much for a broad-use API.

If a developer wants to time a particular hot spot on users' machines, they
will be able to do that with User Timing. And if they want to see all of
the script execution time, they can use developer tools.

James

On Wed, Feb 15, 2012 at 2:03 AM, Alois Reitbauer <
alois.reitbauer@dynatrace.com> wrote:

>  A while ago, I submitted a list of potential future work targeted at
> getting more insight into the runtime behavior of JavaScript heavy web
> applications. As a first result out of these initial ideas I came up with a
> proposal how to extend the Performance Timeline to expose JavaScript
> execution time information.****
>
> ** **
>
> As formatting is limited for mailing list messages I posted a formatted
> and easy to read version of the proposal at
> http://blog.dynatrace.com/2012/02/15/specification-proposal-for-javascript-timing-in-browsers/
> ****
>
> ** **
>
> Please provide feedback. ****
>
> ** **
>
> // Alois****
>