Activity response, startup times

Question

I'm interested in what is a reasonable start up time or behavior for applications on smart phones.

This is simply when you click an icon on the launcher (as it may be called on Android) to the moment you get the first animation / update suggesting something is happening, to finally when the UI is completely ready.

I wonder how much difference a person can see in these scenarios? Is it worth optimizing start up of an application to gain 100ms, or say 250ms?

Is it better to have a progressive start up decorated with animations compared to a simple best effort start? Any suggestions on where in time this break point lies?

I'm mostly interested in numbers possibly backed from experimental studies.

Answer 1

Great question. The closest answer I found was in this infographic which states that the maximum users are willing to wait is 5 seconds after which they will exit the app.

A snippet from the screenshot which pertains to loads times for apps

Also do note that the different app stores do enforce an limit on the load time for an app. To quote this article

All mobile operating systems – iOS, Android, and even Windows – enforce a maximum app startup time. For iOS, the limit is about 15 seconds, and if your app isn’t running by then the operating system will kill it.

With regards how to optimize your performance and how to keep the user engaged, I strongly recommend reading this excellent article from smashing magazine which has this to say:

Speed up perceived performance

The designer cannot control performance all of the time. The network might be slow; the device might be running other tasks in the background; certain operations might require a lot of calculation. If the user at least perceives that they are not losing time, then the app will make a solid impression. Design can help communicate this, even during unexpected delays.

The first step is to identify flows that will likely have delays (fetching back-end data, performing a lot of calculations, etc.). The second step is to guide users through these delays by introducing additional steps that they would perceive as being necessary (showing loading animations, displaying useful tips, etc.).

The following set of images shows possible steps in a content search:

The user here experiences four steps:

• Hits the search button.
• Sees a loading animation.
• Sees the first part of the list, with textual content and placeholder images (which could be stored in the app itself).
• Sees the actual thumbnail images appear.

The user experiences short steps, rather than jumping directly from step one to four, and so perceives progress rather than delay.

Another example which is recommended is doing partial loads as shown below:

Another example is when an app starts loading up. By first displaying a picture that matches the application’s layout, the user gets the impression that the app is loading more quickly. The screenshot below illustrates this; however, the perceived performance could be sped up even more by adding a simple progress notification in the blank space of the first screen. This would avoid the impression that something is waiting to be loaded. (In case of a slow connection the app does show a loading notification, thereby communicating progress to the user for that situation).

The article also has two other recommendations namely smart loading and background loading which can help create an illusion of faster loading

Smart loading

Smart-loading mechanisms, such as lazy loading, first load visible content and then move on to content below the fold. This technique reduces the user’s waiting time and thus makes for a smoother experience.

Background loading

This is another well-known example. Performance depends on whether the background is one large image, an amalgamation of small tiles (say, to create a texture) or a pure algorithm. The best solution depends on the situation.

I also recommend reading this research paper Fast App Launching for Mobile Devices Using Predictive User Context which talks about using cache and proactive content updates to quickly load apps

Answer 2

It greatly varies depending on the utility and use case of the app.

In the general case, initial start up time should be as short as possible and only lengthened if a slower start up can significantly improve the responsiveness of the rest of the app after start up. This means less "jitters" and improved perception of speed after the initial load.

Gmail is a good example of an app that takes a bit to load first time, then is mostly very responsive after the initial load. (I'm talking about the web app more so than the mobile one, since the web app happens to be a great, general case example of slow start up, fast run-time response) Gmail is a great app to allow a slower load time because of the follow attributes:

• It's often open for a long time. Many will leave Gmail open in a tab, or go through very many emails at once, so the initial load time is less significant due to the extended session time
• A user will generally navigate through many "pages" or bits of content in a single session
• Gmail is complicated and it does a lot. It's not the particularly user's problem, but larger apps may take longer to load, and the more a user can do in an app the more they're likely to forgive it.

Compare this to a Camera app. A Camera app should loud as quickly as possible, and users are a lot less likely to be forgiving.

• When I'm opening a Camera app, it's very likely I want to take a picture now. Sometimes I want the picture before I even took out my phone. There's no greater sin a camera app can commit than making a user miss a shot because it was still loading.
• Camera apps are often used in short bursts. Most of us aren't professional photographers, we're just snapping a quick pic of our friends, or the meal, or that funny dog over there. We get in and out, so there's not too much to "eager load".
• Note professional camera apps may have very different requirements; when taking multiple shots or tinkering with many settings, noticeable lag after start up will be a problem. That's not the get-in, get-out experience "lazy loaded" applications are usually good for

As for specific numbers, there's never a magic number or cutoff; temper your expectations. A faster than average app is usually preferable even if it's already below a magic cutoff, and an app may simply have to be slower than other apps or even slower than a common guideline. Only your users can tell you what's really too slow.

While there's no magic number, there's some good rough guidelines research has provided; KISS Metrics has a great article on How loading speed affects your bottom line though it's focused more on websites than apps (the lines between which are ever blurring).

One of the most important take-aways is that most mobile users would wait between 6-10 seconds for a page to load, while 47% of respondents expect pages to load in 2 seconds or less. Don't forget just because people are willing to wait X seconds doesn't mean they like waiting X seconds. For a native app I would tend to expect better performance of course, since that's based on mobile internet speeds. Also give a read to What is Slowing Down Your Mobile Apps? courtesy of Mervin's answer

Also remember "instant" is always a great goal. If your users perceive loading as instant, that's about the best you could hope for. Times under 200ms is a good goal for "instant" response times; that's about typical human reaction time. Eric's answer here is a good summary of "instant" response timing and relevant cutoffs.