HTML UI Responsiveness tool in Visual Studio 2013

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.

Interacting with the timeline details

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.

The Timeline details is where your primary investigation will occur. It displays a detailed view of CPU utilization that is categorized/colored by subsystem (e.g. resource loading, JavaScript, styling) and labeled by operation type (e.g. DOM event, Timer, Layout). Most of the events occur on the UI thread, but for events that don’t (e.g. image decoding always happens on a background thread), the name of the event will include a thread ID, which simply helps distinguish that the event did in fact occur on a background thread.

When you find an event of interest, you can further investigate it using the following gestures:

• Selecting the event row, which will display additional details about it in the detail pane (the area to the right of the Gantt chart). For many events, this extra data assists in identifying the event and understanding why it occurred (e.g. the type of event, the elapsed time of a timer)
• Expanding the event row (if applicable), which will display the “child” events it synchronously triggered (e.g. a DOM event triggering HTML parsing due to setting innerHTML on a DOM element)

o Because an event can trigger other events, the tool supports the notion of “Inclusive” vs. “Exclusive” time, which allows you to identify whether an event was expensive because it was churning on its own work (e.g. long CSS parsing due to a huge stylesheet) or because it instigated additional work and was waiting for it to complete (e.g. a requestAnimationFrame callback that had very little JavaScript but triggered inline layout due to a call to getComputedStyle)

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. , ), along with their individual parsing/evaluation costs, which make it easier to optimize page load times

Example showing the set of JavaScript files loaded as a result of the parser

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

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!

Measuring an isolated scenario

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:

• DOMContentLoaded - Helps identify at what point a page’s synchronous sub resources (stylesheets and non/async or deferred scripts) were fully downloaded and the DOM tree has been constructed
• Load - Helps identify at what point a page’s entire sub resources (including images) were fully downloaded and all DOMContentLoaded/Load event handlers have completed
• Navigation - Helps identify at what point a page navigation/refresh occurred

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.

We want to hear from you!

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.

We’ll be posting subsequent articles which describe performance patterns to look for in the tool, as well as how to resolve them in your code. In the meantime, you can see the tool in action in the following //build 2013 talk: “Developing High Performance Websites and Modern Apps with JavaScript Performance Tools”.

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.