Reducing your app's loading time (HTML)
The user's first experience with an app begins by tapping the app tile to launch it. First impressions matter, so it's to important to limit how much time the user spends waiting while the app launches. How you package your app and reference your code files can improve your app launch time.
Keep content within the app package
Take advantage of bytecode caching
To ensure that your app benefits from bytecode caching:
When an app begins loading, the first thing Windows loads is the HTML Start Page specified by the package manifest. The Start Page is the starting point for your app and determines which content and code gets loaded and executed first. How you include your code can have a big impact on performance. Code can be included through static markup, dynamically loaded, or declared inline in the start page's HTML. Here are the different ways to include code:
Use static markup in the Start Page
var s = document.createElement(‘script'); s.src = ‘code.js'; document.head.appendChild(s);
We recommend dynamic loading only when:
Load only what you need
The next sections describe a few ways to avoid loading files that your app doesn't need immediately:
This example doesn't use deferred loading:
The second way to use the script element is to specify the defer attribute. The script attribute informs the host process that the code located within this script is not vital to the app's initialization and can be loaded and executed at a later point. The next example uses deferred loading:
Most games are loaded this way. When a game is first launched, usually it gets to the main menu screen fast, because only the items needed for the menu screen are loaded. When a user gets further along in the game (creates or loads a game), then the game loads the remaining data.
Cache the app's fragments
You can use the WinJS.UI.Fragments.cache function to cache a fragment. After a fragment is cached, your app can display it quickly by using the renderCopy function. If the user interacts with the fragment right when your app is loaded or soon after, cache the fragment during activation or immediately after. If you don't explicitly cache a fragment, the app will cache it for you the first time it uses the fragment.
There's no need to track which fragments you cached or when you should clear the fragment cache. The WinJS maintains the cache for you.
Because caching a fragment is about performing the task ahead of time and the cached content consumes memory, and also it takes CPU time and IO to build the cache, we recommend that you:
- For a small app that activates quickly, cache all fragments before completing activation.
- On the other hand, if there is a lot of fragment content and the activation time for the app is already long, cache the fragments after activation is done. Cache the fragments one by one instead of caching all of them at once to avoid tying up too many resources when user might be interacting with the app.
- If you're not sure whether you should cache your fragments during activation or after, try both approaches and measure how much time it takes for the app to launch.