Plan for performance
Slow, unresponsive, battery-intensive app experiences are among the biggest causes of user frustration. Apps that are fast, responsive, and battery-aware can help keep users satisfied and engaged. As you plan your Windows Store apps, be sure to keep performance in mind.
Performance is a feature that should be planned for, designed, and tested, just like your apps' other features. Follow this process to help plan your apps for performance.
- Set performance goals for your apps.
- Design for performance.
- Instrument your apps for performance.
- Test and measure your apps against your performance goals.
- Iterate and improve your apps' designs based on the results of your performance tests.
Here are the details for each of this process's steps.
Your apps' performance goals should be specific and measurable. To make these goals specific, it may be helpful to think about how fast, fluid, and efficient your apps can be: how long it takes users to complete their tasks in your apps, how responsive your apps are in responding to user interactions, and how well your apps conserve battery life.
One starting approach is to think of the acceptable time ranges for users to complete their tasks in your apps. We call these time ranges interaction classes. For each of these interaction classes, you could assign for example a label, a perceived user sentiment, a target time period, and a maximum time period. Here are some suggested interaction classes with examples for each.
Interaction class label | User perception | Target | Maximum | Examples |
---|---|---|---|---|
Fast | Minimally noticeable delay | 100 milliseconds | 200 milliseconds | Bring up the app bar; press a button (first response) |
Typical | Quick, but not fast | 300 milliseconds | 500 milliseconds | Resize; semantic zoom |
Responsive | Not quick, but feels responsive | 500 milliseconds | 1 second | Navigate to a different page; resume the app from a suspended state |
Launch | Competitive experience | 1 second | 3 seconds | Launch the app for the first time or after it has been previously terminated |
Continuous | No longer feels responsive | 500 milliseconds | 5 seconds | Download a file from the Internet |
Captive | Long; user could switch away | 500 milliseconds | 10 seconds | Install multiple apps from the Windows Store |
After you have a set of interaction classes, you could assign them to your apps' performance scenarios. For each scenario, you could assign for example the app's point-in-time reference, a portion of the user experience, and an interaction class. Here are some suggested performance scenarios for an example food and dining app.
Scenario
Time point
User experience
Interaction class
Navigate to recipe page
First response
Page transition animation started
Fast (100-200 milliseconds)
Responsive
Ingredients list loaded; no images
Responsive (500 milliseconds - 1 second)
Visible complete
All content loaded; images shown
Continuous (500 milliseconds - 5 seconds)
Search for recipe
First response
Search button clicked
Fast (100 - 200 milliseconds)
Visible complete
List of local recipe titles shown
Typical (300 - 500 milliseconds)
After you have a set of performance scenarios, you'll be better able to test, analyze, and improve how fast your app is.
For smooth user responsiveness, specific measurable performance goals for your apps can include:
- No screen redraw stops and starts (glitches).
- Screen animations happen at 60 frames per second (FPS), 16 milliseconds of CPU and graphics processing unit (GPU) work per frame.
- When a user pans your app, you should target presenting up to 3 to 6 pages of content per second.
For efficiency, specific measurable performance goals for your apps can include:
- Maximum memory usage at or below a specified CPU percentage and memory in megabytes at all times.
- Whenever the user isn't using the app, the CPU and disk percentages stay at zero.
Most of the performance work you do naturally reduces the amount of power your app consumes. The CPU is a major consumer of battery power on devices, even at low utilization. Windows 8 tries to keep the CPU in a low power state when it is idle, but activates it every time you schedule work. You can further reduce your app's consumption of battery power by ensuring that your app doesn't have timers unnecessarily schedule work on the CPU when it is idle. For example, an app might poll for data from web services and sensors (such as the Global Positioning Systems (GPS)). Consider battery consumption when deciding how often you poll for data.
This is also an important consideration for animations that require constant updates to the screen and keep the CPU and graphics pipeline active. Animations can be an effective in delivering a great user experience, but make a conscious choice about when you use them. This is particularly important for data-driven apps where the user may be looking at your app but not interacting with it. For example, a user may spend a while looking at content in a news reader or photo viewer without interacting with the app. It can also be wasteful to use animations in snap mode because the user is not giving the app their full attention.
Many apps connect to web services to get new info for the user. Reducing the frequency at which you poll for new info can improve your battery consumption.
Reducing memory helps avoid sluggishness and is even more important for Windows Store apps because of the Process Lifetime Management (PLM) system. The PLM system determines which apps to terminate, in part, by the app's memory footprint. By keeping your app's memory footprint low, you reduce the chance of it getting terminated when it is not being used. For example, you can reduce your app’s memory footprint by releasing unnecessary resources such as images on suspend.
The PLM system may also choose to swap out your app to disk, and swap it back into memory the next time it is switched to. If you lower the memory footprint of your app, it will resume faster.
After you have your performance goals, you can use them to help influence your app's design.
As you design your app, keep your performance goals in mind. Using our example food and dining app, after the user navigates to the recipe page, you might use virtualization as a technique to more quickly load the initial ingredients list but not display any accompanying images until later. Here are some other areas to consider.
For displaying multiple pages of content, performance design and coding techniques include:
- Use virtualization for lists and grids, with constant-sized items, whenever possible. For details, see Using virtualization with a list or grid.
- Develop apps for only the first page of UI to be responsive. Don't load additional UI until the user needs it.
- Schedule lower-priority work for later. For details, for Windows Store apps using JavaScript, see the WinJS.Utilities.Scheduler namespace and the HTML Scheduler Sample. For Windows Store apps using C++, C#, or Visual Basic, see Asynchronous programming, the Dispatcher property, the CoreDispatcher class, and the Multiple Views Sample.
- Collapse content until the user needs it. For details, for Windows Store apps using JavaScript, see display property for
display:none
. For Windows Store apps using C++, C#, or Visual Basic, see the Visibility property for Collapsed.
For displaying rich visuals and functionality, performance design and coding techniques include:
- Defer loading UI and code as much as possible.
- Use code-free UI—large portions of hard-coded HTML or Extensible Application Markup Language (XAML) that the runtime can load in batches—whenever possible.
- Identify distinct functionality for your app and load minimal elements whenever possible.
- Display portions of the UI to users in multiple stages.
- Images you load should be loaded at a size that is appropriate for the view in which you are presenting it, using the GetThumbnailAsync method.
- For animations in Windows Store apps using JavaScript, use Cascading Style Sheets (CSS) Animations, the WinJS.UI.Animation namespace, or both. See also the HTML animation library sample.
- For Windows Store apps using JavaScript, position UI components with HTML and CSS, avoiding inline layout such as the offsetWidth and offsetHeight properties.
- For Windows Store apps using C++, C#, or Visual Basic, use XAML theme transitions and animations. For details, see Fast and fluid animations in your Windows Store app and the XAML personality animations sample.
For displaying live content, performance design and coding techniques include:
- Identify content freshness goals. For example, is the goal to refresh content every few seconds? Or is refreshing content every few minutes, every few hours, or even once a day an acceptable user experience?
- Cache content whenever possible. For more info, see:
- For Windows Store apps using JavaScript, see the Application Cache API.
- The
Cache-Control
header. For details, see the CacheControl property and the HttpClient sample. - The LocalFolder and LocalSettings properties.
- When caching content isn't possible, show a responsive UI as quickly as possible—a UI that users can navigate, but shows some indication to the user that the app is still trying to load some content.
- Transition from cached to live content in a way that is not jarring to the user. For example, the app won't change the position of content under the user's finger as the app loads live content.
- Prefetch content. For details, see:
- For automatic prefetching, see the ContentPrefetcher class.
- For manual prefetching, see the Windows.ApplicationModel.Background namespace and the MaintenanceTrigger class.
For launching apps, performance design and coding techniques include:
- Defer the app's splash screen, and don't extend the app's splash screen unless necessary. For details, see Creating a fast and fluid app launch experience. See also How to extend the splash screen (Windows Store apps using JavaScript) and How to extend the splash screen (Windows Store apps using C++, C#, or Visual Basic).
- Disable animations that occur immediately after the splash screen is dismissed, as these will only lead to a perception of delay in app launch time. For details on Windows Store apps using JavaScript, see the disableAnimations function.
For resuming apps, performance design and coding techniques include:
- Transition smoothly from cached to live content in a way that is not jarring to the user. For example, the app won't change the position of content under the user's finger as the app loads live content.
- Don't relaunch the app or reanimate content.
- Higher memory usage translates into slower app resumes. Manage your app's memory as follows:
- Reduce your code's working set.
- Avoid memory leaks by unregistering event handlers and dereferencing visual elements whenever possible.
- For Windows Store apps using JavaScript, use the createObjectUrl method and oneTimeOnly property.
- If possible, avoid creating hybrid apps that use both HTML/JavaScript and XAML to minimize circular references.
For resizing and rotating apps, performance design and coding techniques include:
- For Windows Store apps using C++, C#, or Visual Basic use the VisualStateManager class.
- For Windows Store apps using JavaScript, use HTML/CSS instead of JavaScript as much as possible.
- Complete only required work immediately, deferring intensive app work until later—your app has between 200 and 800 milliseconds to complete work before the user sees your app's UI in a cropped state.
For panning through content, performance design and coding techniques include:
- Plan for 3 to 6 pages per second of user panning.
- Virtualize large sets of items. For details, see Using virtualization with a list or grid.
- Use project templates with the lowest number of elements that you can.
- Render content in multiple stages.
Note that as you go, you may discover that there are other general performance-related design considerations that don't match up to any of these performance scenarios. For example, what happens if the device has an intermittent wireless connection, has a slower dial-up connection, or has no Internet connection at all? In the case of our example food and dining app, one approach may be to cache the accompanying images after they are initially downloaded. For other techniques, see Connection usage data.
With your performance-related designs in place, you can start coding your app.
As you code your app, you can add code that logs messages and events at certain points while your app runs. Later, when you're testing your app, you can use tools such as Windows Performance Recorder and Windows Performance Analyzer (both are included in the Windows Performance Toolkit) to create and view a report about your app's performance. In this report, you can look for these messages and events to help you more easily analyze the report's results.
The Windows Runtime provides logging APIs, backed by Event Tracing for Windows (ETW), that together offer a rich event logging and tracing solution for Windows Store apps. The APIs, which are part of the Windows.Foundation.Diagnostics namespace, include the FileLoggingSession, LoggingActivity, LoggingChannel, and LoggingSession classes.
To log a message in the report at a specific point while the app is running, create a LoggingChannel object, and then call the object's LogMessage method, like this.
// using Windows.Foundation.Diagnostics;
// ...
LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");
myLoggingChannel.LogMessage(LoggingLevel.Information, "Here's my logged message.");
// ...
To log start and stop events in the report over a period of time while the app is running, create a LoggingActivity object, and then call the object's LoggingActivity constructor, like this.
// using Windows.Foundation.Diagnostics;
// ...
LoggingActivity myLoggingActivity;
// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{ // After this logging activity starts, a start event is logged.
// Add code here to do something of interest.
} // After this logging activity ends, an end event is logged.
// ...
For more examples, see the LoggingSession sample and FileLoggingSession sample.
After you've instrumented your app's code, you can test and measure your app's performance.
After you've instrumented your app, use the following techniques and tools to test how your app stacks up against your original performance goals:
- Test against a wide variety of hardware configurations that you think users will have, including all-in-one and desktop PCs, laptops and ultrabooks, and tablets.
- Test against a wide variety of screen sizes that you think users will have. Note that while wider screen sizes can show much more content, bringing in all of that extra content can have a negative impact performance.
- Eliminate as many random testing variables as you can. For example:
- Turn off background apps on the testing device. To do this, in Windows, select the Settings charm > Change PC settings > PC and devices. Select each active app in the Lock screen apps area, and select Don't show quick status here.
- Create native code images on the testing device for Windows Store apps built for Windows using C# or Visual Basic. To do this, Windows, from the Desktop, open Action Center. In the Maintenance area, under Automatic Maintenance, select Start maintenance.
- Run the app multiple times to help eliminate random testing variables and help ensure consistent measurements.
- Test for reduced battery consumption. When you create an app, be aware that the type of computer that your users have might have significantly less power than your development environment. Windows 8 was designed with low power devices, such as tablets, in mind. Also, Windows RT uses these same design principles to take advantage of the low power consumption characteristics of ARM-based platforms. Windows Store apps need to do their part to ensure that they perform well on these devices. Operations that seem to run fast on your development machine can have a big impact to the user-experience on a low power device. As a heuristic, expect that a low power device is about 4 times slower than a desktop computer, and set your goals accordingly.
- Use a combination of toolsets like Microsoft Visual Studio and Windows Performance Analyzer to measure app performance. Visual Studio is designed to provide app-focused analysis, such as source code linking. Windows Performance Analyzer is designed to provide system-focused analysis, such as providing system info, info about touch manipulation events, and info about disk input/output (I/O) and GPU cost. Both toolsets provide trace capture and export, and can reopen shared and post-mortem traces.
- Before you submit your app to the Windows Store for certification, be sure to incorporate into your test plans the performance-related test cases as described in the "Performance tests" section of Windows App Certification Kit tests and in the "Performance and stability" section of Windows Store app test cases.
After you analyze your performance test results, determine if any changes are needed, for example:
- Should you change any of your existing app performance goals?
- Should you change any of your current design decisions?
- Should you add, remove, or change any of your instrumentation in the code?
If any changes are needed, go back through the start of this process and iterate.
Performance (Windows Store apps)
General best practices for performance
Performance best practices for Windows Store apps using JavaScript
Performance best practices for Windows Store apps using C++, C#, or Visual Basic