Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
(Posting this on behalf of Jonathan Carter who authored this post)
Performance is a critical aspect of any 5-star rated app. Users expect pages to load quickly, interactions to respond immediately and animations to be fluid. While it’s easy to recognize the importance of these qualities, achieving them can often prove challenging, especially with the tight demands they impose (e.g. 60 FPS requires <16ms per frame).
The key to maintaining a responsive app is keeping the UI thread as free as possible. This way, it will be ready to respond to user-interaction (e.g. button click, scrolling) as soon as it occurs and will be able to maintain a fast and consistent frequency when producing new frames within an animation/game.
You can begin a new profiling session by selecting the checkbox and clicking the Start button. At this point, you can return to your app and exercise the scenario you’d like to investigate. When completed, return to Visual Studio and click the Stop collection link (or Stop button) to end your profiling session and begin analyzing the collected data.
Once the analysis has completed, you’ll be presented with a performance report that you can begin investigating for optimization opportunities.
Additionally, the timeline also indicates the frame rate that your app was achieving throughout the duration of the session, which makes it easier to understand how CPU utilization was affecting the ability to maintain a consistent visual throughput. This makes it possible to spot “dips” in your frame rate and correlate them to the offending operations.
Once you’ve identified a region of interest within the session (based on examining either the CPU utilization and/or Visual throughput graphs), you can investigate that period of time by click-and-dragging that selection on either of the graphs (or the ruler). As you change your selection, the Timeline details will automatically update to reflect this filtered view. If you need to adjust your selection to include more or less time, you can select the handles on the ruler and use the left/right arrow keys to achieve more fine-grained control.
When you find an event of interest, you can further investigate it using the following gestures:
By default, the timeline is sorted sequentially, which means that events that occurred earlier in time will appear higher (and to the left) than events which occurred later in the current selection. If you’re interested in identifying the most expensive events (based on inclusive duration), you can change the Sort by option to “Duration (inclusive)” and the timeline will immediately bubble up the “hot paths” that contributed the most to your bottleneck.
There are many event types, lots of operation metadata and numerous combinations of parent/child relationships (e.g. HTML parsing triggering Script evaluation, a DOM operation triggering Paint, Timer triggering CSS parsing). The data can be vast, but this expressive profiling information is what makes the tool so powerful and allows you to make informed optimizations.
To illustrate the types of rich data/patterns that the tool surfaces, the following are some unique scenarios that it allows you to identify:
1. Sub-resources loaded by your app (e.g. <script>, <link>), along with their individual parsing/evaluation costs, which make it easier to optimize page load times
2. Event-driven causality around why script is running (e.g. event handler, timer, requestAnimationFrame callback), along with the identifiable metadata about the event, and source navigation capabilities, which make it easier to optimize user-interaction
Example showing the target element, callback function name and source location of a specific DOM event
3. DOM calls made within script, along with their synchronous rendering side-effects (if any)
Example showing how calling getComputedStyle on the specific <div> triggered an inline layout
4. DOM elements that were affected in a specific layout/style calculation/paint pass, along with the exclusive time they contributed to the operation, which makes it easier to optimize rendering costs
Example showing the set of elements that required their layout to be re-computed
5. Much much more!
In order to make a profiling session efficient and actionable, you want to scope down the area of investigation as far as possible. This way, you’re not trying to interpret data that doesn’t actually relate to the problem you’re trying to solve. Because this capability is so critical to the typical performance analysis workflow, the HTML UI Responsiveness tool allows you to instrument your app with “milestones of interest”/scenario boundaries which can significantly help provide the context needed to decide where in the trace you should focus.
To make use of these markers, you simply add calls to the performance.mark method at the relevant locations within your codebase. When you subsequently profile the app, these calls will show up as marks (the legend refers to them as “User marks” because their app-specific) on the ruler.
With your scenario-specific marks in place, you can easily identify the period of interest on the graphs, select its timespan and begin an isolated investigation. Additionally, the ruler within the Timeline details also display your marks, which allows you to see the exact events which occurred during the problematic period you’ve selected.
To help bootstrap your investigations in lieu of having any app-specific markers (or supplement your custom marks), the tool also displays ruler marks which represent fundamental events that occured during a profiling session (called “App lifecycle events”).
The following event types are currently supported:
In some cases, these marks alone can help isolate specific scenarios. For example, being able to identify the period of time between a navigation and the subsequent DOMContentLoaded event would allow you to investigate the cost of sub-resources being loaded and how they individually affect page load time.
The HTML UI Responsiveness tool provides a lot of power and visibility into data that was otherwise difficult to ascertain. We hope this allows you to make more informed optimizations regarding your app’s performance, which will ultimately contribute to its success.
Most importantly, however, we want to hear from you! If you get a chance to evaluate the tool, please let us know how your experience went, as well as any feedback/suggestions/complaints you may have. You can reach out by means of UserVoice, Connect, Twitter (mention “HTML UI Responsiveness”), or by asking questions in the MSDN diagnostics forum.
Why Windows Store only? The engine behind is IE10 or IE11, right? Why can't we profile the UI responsiveness of a web application running in the browser the same way?
The HTML UI Responsiveness profiler is actually part of the new F12 Developer Tools in IE11, so you can use the exact same tool against Windows Store apps in Visual Studio and IE apps using F12. If you downloaded Windows 8.1 you can try it out today.
At the moment I'm still on Win7 so I can't test IE11 but I'm looking forward to it.
This is really cool. Wondering if it has APIs that we can call and consume the data..does it?
Unfortunately, as of now there aren't any APIs that you can call and consume the data. This is something that is being discussed, but as it's currently not supported, would you mind logging a suggestion on visualstudio.uservoice.com? This is how we track customer requests, so that they are implemented in order of popularity.