mozilla

Revision 380473 of Optimizing startup performance

  • Revision slug: Apps/Developing/Optimizing_startup_performance
  • Revision title: Optimizing startup performance
  • Revision id: 380473
  • Created:
  • Creator: Sheppy
  • Is current revision? No
  • Comment getting started on this content, based off of http://mozakai.blogspot.com/2012/07/bananabread-or-any-compiled-codebase.html

Revision Content

An often overlooked aspect of app software development—even among those focusing on performance optimization—is startup performance. How long does your app take to start up? Does it seem to lock up the device or the user's browser while the app loads? That makes users worry that your app is crashed, or that something else is wrong. It's always a good idea to take the time to ensure that your app starts up nicely. This article offers tips and suggestions to help you achieve that goal.

Starting up nicely

Regardless of platform, it's always a good idea to start up as quickly as possible. Since that's a universal issue, we won't be focusing on it too much here. Instead, we're going to look at a more important issue when building Web apps: starting up as asynchronously as possible. That means not running all your startup code in a single event handler on the app's main thread.

Instead, you should write your code so that your app creates a Web worker that does as much as possible in a background thread. Then, anything that must be done on the main thread should be broken up into small pieces so that the app's event loop continues to cycle while it starts up. This will prevent the app, browser, and/or device from appearing to have locked up.

Why is it important to be asynchronous? Other than the reasons suggested above, consider the impact of a non-responsive page or user interface. The user is unable to cancel if they launched your app by mistake. If the app is being run in a browser, it's possible the user may get an "unresponsive app" or "slow script" notification. You should present some kind of interface, such as a progress bar, so that the user knows how much longer they'll need to wait while your app starts up.

 

Revision Source

<p>An often overlooked aspect of app software development—even among those focusing on performance optimization—is startup performance. How long does your app take to start up? Does it seem to lock up the device or the user's browser while the app loads? That makes users worry that your app is crashed, or that something else is wrong. It's always a good idea to take the time to ensure that your app starts up nicely. This article offers tips and suggestions to help you achieve that goal.</p>
<h2>Starting up nicely</h2>
<p>Regardless of platform, it's always a good idea to start up as <strong>quickly</strong> as possible. Since that's a universal issue, we won't be focusing on it too much here. Instead, we're going to look at a more important issue when building Web apps: starting up as <strong>asynchronously</strong> as possible. That means not running all your startup code in a single event handler on the app's main thread.</p>
<p>Instead, you should write your code so that your app creates a <a href="/en-US/docs/DOM/Using_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web worker</a> that does as much as possible in a background thread. Then, anything that must be done on the main thread should be broken up into small pieces so that the app's event loop continues to cycle while it starts up. This will prevent the app, browser, and/or device from appearing to have locked up.</p>
<p>Why is it important to be asynchronous? Other than the reasons suggested above, consider the impact of a non-responsive page or user interface. The user is unable to cancel if they launched your app by mistake. If the app is being run in a browser, it's possible the user may get an "unresponsive app" or "slow script" notification. You should present some kind of interface, such as a progress bar, so that the user knows how much longer they'll need to wait while your app starts up.</p>
<p>&nbsp;</p>
Revert to this revision