This continues a series of posts on the F12 Developer Tools included with Internet Explorer (since version 8) to help you improve your websites with tools to review content, diagnose issues, improve performance, and more:
- Part 1 – Introduction
- Part 2 – Working with HTML and CSS
- Part 5 – Network Performance and Debugging
If this is your first look at the F12 Tools, I recommend you skim through the introductory post first.
Let’s fire up the IE9 Developer Tools (press F12 or choose Tools –> F12 Developer Tools) and take a look.
Introduction to Profiling
Just click “Start profiling”, load a page and/or use page functionality, and click “Stop profiling”. You can also use F5 and Shift+F5 to start/stop, though I rarely find that easer.
When the session is stopped a report of the instrumented script is shown, including the following by default:
- Function name
- Count of times called
- Inclusive time (ms) – Time in the function plus any functions it calls
- Exclusive time (ms) – Time in the function only
- URL (of file containing the function)
- Line number
Viewing Function Source Code
- Tip: Typically you can click to source where the URL field is specified. In this case playSound(), but not play() or getElementById():
- Tip: You can also add the Function type column (see next) and look for “User” functions.
Click the Profiler tab to return to the list.
Customizing and Sorting the Report
There are more details available via columns that are hidden by default. To show them, right-click in the report and choose “Add / Remove columns”:
This will give access to:
- Inclusive time % – Percent of total time
- Exclusive time %
- Avg time (ms)
- Max time (ms)
- Min time (ms)
- Function type – User, DOM, Built-In
The right-click menu also enables sorting by displayed columns, but you’ll probably find it easier to click on column headers to toggle between sorting ascending and descending.
There are two options available for viewing profiling report data: Functions and Call Tree views.
By default, reports are shown in Functions view, listing content at the function level (one line per function) and allow an easy way to see where the most calls are made and where time is spent.
Call Tree View
Call Tree view shows the same data (each line is still a specific function), organized into a hierarchy by caller/callee relationships. From the root function(s), expand to see functions were called (and continue to expand to functions they in turn called.)
- Tip: Unlike in Functions view, the same function may appear in more than one place because it was called by different parts of the application. In the above picture, playSound() appears under endPieceFlip() and startPieceFlip().
Sorting in Call Tree view works at the group level, with each subgroup sorting individually.
As with other areas of the F12 Tools, use the Search box to find functions by name:
As you create profiling sessions, you may notice the report drop-down is keeping track:
Use this to switch between individual profiling sessions. These are retained only for the life of the window.
- Tip: You can copy items (tab-delimited format) from the report directly. Click, CTRL+Click (for multiple items), or CTRL+A (all items), then CTRL+C or right-click and choose “Copy” to add details to the clipboard.
Once in Excel, you can decide where to go next. Build up an archive to document application performance during development, create various analysis graphs, or even extend Excel with .NET to help detect changes and trends from session to session.
Performance Optimization Tips
Now that you know how the profiler works, what should you be looking for? It’s a huge topic, subject of books, presentations, and articles, but here are some ideas to get you thinking:
- High function counts – Having many calls to a function isn’t necessarily a problem, but it’s a good place to start looking. Can you refactor to batch requests together? Move conditionals earlier to prevent code path execution (a good use of the Call Tree view)? Make asynchronous requests?
- Repeated calls – Calling a function with the same arguments repeatedly? Recomputing values frequently? They may be a good candidates for caching and/or precomputing common requests (server- or client-side).
- Use realistic data – Some issues only manifest themselves in production scenarios. Test with realistic data and conditions… before your users do (e.g. testing that document processor using “Hello world!” might not be enough.)
Again, just a starting point, and many books and articles await you. For more ideas, watch Jason Weber’s “50 Performance Tricks to Make Your HTML5 Web Sites Faster” session from Mix11.
Next: Part 5 – Network Performance and Debugging
In the next article, we’ll take a look at the Network feature that was added to the F12 Tools with Internet Explorer 9.