Add javascript timing metrics to timing panel onLoad if available

[mindsocket]

Some browsers support navigation timing via javascript. Since these metrics fit the category of timing, this commit adds a section to the timing panel containing key metrics from the browser, triggered soon after the onLoad event.

The change is plain javascript, so no library dependencies.

Background:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html

Screenshot:
http://dl.dropbox.com/u/15940111/browser_timing.png

Tested on Chrome 22 and Firefox 14

[SiDChik]

Nice feature, very usefull. Waiting for release:)

[mindsocket]

Is there anything I can do to help get this merged?

[ebertti]

👍

[jezdez]

I like the idea two, but can you do two things:

• add a fallback for browsers that don't support it (which are those btw?)
• afaik there are more than those 8 events that can be tracked, should DDT support more?

[mindsocket]

• The javascript already includes that check (if (perf) {...} wraps most of the code in the commit)
• I deliberately chose a subset of the timing events for 2 reasons...
  • Some are effectively duplicates (eg one event starts at the exact same time as another ends)
  • Some are not relevant to application debugging or performance in development (eg redirect time, domain lookup time)

[jezdez]

Thanks @mindsocket, that sounds sensible. Regarding the fallback, I saw the condition check for perf but missed the .djDebugBrowserTiming block being hidden by default and only made visible if supported. Apologies.

With regard to the second point, I'm not sure if we can make an educated guess about all applications and which performance measuring is useful (e.g. domain lookup time isn't totally useless when debugging a frontend issue). Do you think we could make that configurable (without adding another setting)? Is there another way to specify all of them?

[mindsocket]

My admittedly opinionated approach was to choose metrics based on those
that are commonly relevant to debugging Django back- and front-end,
particularly at development time, rather than clutter up the timing data
for application developers with network- and DNS-related metrics (often a
production concern). It's still possible for developers to use the browser
console for the complete set. I'm not strongly of this opinion though, it
just seems a pragmatic one to me.

So, in terms of an alternative solution, one could simply add all of the
PerformanceTiming values listed at:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html

This appears to be possible without an explicit list by iterating over the
timing object in the Javascript block. Using Chrome console I put together
this proof-of-concept:
for (var metric in window.performance.timing) {
console.log(metric, window.performance.timing[metric]);
}

One way to make it "configurable" might be to have a basic list shown by
default, with an expandable section for the rest.

Let me know what you think, happy to let you run with it, or I can resubmit
w/ changes.

On 3 March 2013 22:33, Jannis Leidel notifications@github.com wrote:

Thanks @mindsocket https://github.com/mindsocket, that sounds sensible.
Regarding the fallback, I saw the condition check for perf but missed the
.djDebugBrowserTiming block being hidden by default and only made visible
if supported. Apologies.

With regard to the second point, I'm not sure if we can make an educated
guess about all applications and which performance measuring is useful
(e.g. domain lookup time isn't totally useless when debugging a frontend
issue). Do you think we could make that configurable (without adding
another setting)? Is there another way to specify all of them?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/319#issuecomment-14345584
.

[jezdez]

You're right, network and DNS stats are less useful for most debugging sessions, but completely leaving them out would be a bad idea. When using the toolbar to get a picture of the performance of a Django site you usually try to get a picture of a bigger stack -- memory, database, cache, search index, etc. -- effectively the single reason why there are so different panels included. Getting access to information about browser performance is incredibly useful to eventually finding issues that other panels cannot describe successfully. I agree it may delude the frontend related performance stats, so maybe we should group the stats in "rendering" and "networking"?

[robhudson]

Very cool idea.

I'm curious... Are the timing set up calls initiated early enough? I haven't played with this yet but was curious.

Also, a waterfall like display would be slick but I wouldn't hold this back as it is.

[mindsocket]

@jezdez We could group them. I'll try to add the others in the coming days. IMHO the commit as is could go out without that in the interests of getting it in front of more eyes for feedback.

@robhudson The timing is captured automatically by the browser (it's a builtin in many modern browsers), the javascript above just grabs it when all is said and done (after page load).

A waterfall (a la SQL queries) is a great idea, if I get a chance I'll take a look

[mindsocket]

I've rebased my commit and rearranged things somewhat.

@jezdez I've included more of the timing events. Also, based on @robhudson 's suggestion I took inspiration from the SQL panel and rendered a timeline of timing events. I'm not sure I like the output exactly as I have it now, but it's an improvement.

[jezdez]

Awesome, this looks amazing @mindsocket! Any feedback @robhudson?

[mindsocket]

Is there anything I can do to help get this merged?

[robhudson]

Apologies... I missed the original call from @jezdez. This looks pretty good.

My only concern is that this is using inline scripts. I've been away from debug toolbar but thought we had some efforts to reduce the amount of inline scripting. (I just found issue #330 which would actually be nice) Would it be much more effort to put this in the javascript file with a hook into the panel display events?

[robhudson]

We might want this removed before merging.

[mindsocket]

I'll move the inline javascript to an included file. As an included panel, is toolbar.js ok for that purpose? If not, where, and should the panel then render the inclusion?

I'll also remove the console logging and replace the load event binding with a jQuery.bind('load'...)

[mindsocket]

I've rebased and updated per suggestions. JS is minified already based on lastest toolbar.js, so hopefully this is good to go.

[jezdez]

LGTM!

[robhudson]

Looks great to me too.

[robhudson]

@mindsocket Is there anything you need to add here based on @andymckay's comment?

[mindsocket]

@robhudson I believe the solution as committed is the only way to ensure loadEventEnd is picked up in all browsers. So, nothing to add AFAIK

[mindsocket]

Committed and pushed a change to the setTimeout call (reduced delay to 0). Tested and working on Firefox and Chrome

[mindsocket]

Ping @andymckay and @robhudson , I think we're close :)

[mindsocket]

Is there anything I can do to help get this merged? I'm going to use it in a talk at PyConAU next month and having it in mainline means I can say it's a more readily available tool.