Speed is an important factor, and if it is not accounted for properly, can make or break an application or service. Often the focus is on measuring system performance; identifying where the most time is being spent, and then optimising the offending area.

Complementary to this, there are several strategies you can employ to make an application feel faster than it actually is. What the user sees on their screen shapes their perception on how fast they think your application/service is.

Why Faster?

It is well documented that users do not like slow websites, or software for that matter. In business terms that means:

  • Amazon: 100ms delay results in 1% sales loss
    (potential $191m lost in revenue in 2008)
  • Google: 500ms delay drops search traffic by 20%
    The cost of slower performance increases over time
  • Yahoo: 400ms delay results in 5-9% drop in full-page traffic
  • Bing: 1s delay results in 4% drop in revenue
  • AOL: Fastest 10% of users stay 50% longer than slowest 10%

- Stats taken from How to Make Apps Feel Faster by Luke Wroblewski

Next we will cover different techniques to make applications feel faster to the end user.

1. Progress Indicators

Users need reassurance that the system is dealing with their request, and that it has not frozen or is waiting for information from them. Progress indicators are used for this very purpose, to signify it is working, and to set expectations as to when it will be complete and ready for use again.

The style of a progress indicator can influence the perception of speed, so much so that it can appear to be 11% faster. These results are achieved by applying ‘a backwards moving and decelerating ribbed’ treatment.

You can view a video of this research from New Scientist below [requires Flash player]:

You can also read the paper about this research

2. Optimistically Perform Actions

You can allow a user to be more effective with their time, and get the impression that an application or service is fast by not requiring them to wait for actions to take place. Thereby freeing them, allowing them to move onto the next action they need to take.

Instagram for example, begins the upload of an image early; once the user has passed the filter stage. Even though they have not yet added a caption, location, or even committed to the posting the image.

Instagram performing actions optimistically. Taken from Secrets to Lightning Fast Mobile Design by Mike Krieger

Instagram performing actions optimistically.
Taken from Secrets to Lightning Fast Mobile Design by Mike Krieger

Once the user has finished the upload flow, the image appears in the user’s feed, even if the upload is still in progress. It just happens to be a local copy of the image. But to them it appears as though it's already on Instagram's service.

Instagram reaps three benefits by making the image upload flow optimistic:

  1. Starting the image upload early in the flow gives them a head start, meaning it will be available to other users, sooner.
  2. Showing the uploaded image in their feed, even though it may not be uploaded yet, gives the user task closure by appearing finished.
  3. Users think their service is quick, even though typically uploading images, especially from a mobile, can be a slow process.

For the second point, the same applies to commenting on Instagram. Once you submit your comment, it appears beneath the picture immediately. Yet, that update is not actually instantaneous, it just appears as though it is.

Mike Krieger, co-founder of Instagram, goes into more detail about how Instagram makes their app feel ‘lightning fast’ in his presentation.

3. Distract

"A watched pot never boils"

Sometimes it is unavoidable, and an application has to become temporarily unavailable for a user, whilst it works on their request.

One of Bruce Tognazzini’s principals for interaction design states:

Offer engaging text messages to [keep] users informed and entertained while they are waiting for long processes, such as server saves, to be completed.

- Latency Reduction in First Principles of Interaction Design by Bruce “Tog” Tognazzini

A prime example of this is on the simulation game Football Manager, which regularly involves long processes:

Football Manager - Loading Distraction

Hints and tips are displayed whilst the users wait for results to be generated, or for games to be created. Messages are used to bring attention to new features, or educate the user so that they can become more effective at playing the game.

Another example is the web-based version of Balsamiq, a wireframing software, which shows the user quotes whilst it is loading:


When providing distractions to the user, it is important to bear in mind that they have a limited time to view the content shown to them. Once the process is completed, that information is taken away from their screen.

4. Progressive Rendering

When designing the pages of an application, the components you place onto a page belong to zones, such as a header or footer. Progressive rendering sends those zones to the user in a prioritised order.

Priority of the page zones are determined by the following factors:

  1. Page placement. Is it near the top, is it ‘below the fold*’ of the screen?
  2. Importance to the user
  3. Is the page asset much slower to return?

*In this case when speaking below the fold, the only reason I am mentioning this is because it is not presently visible, therefore less important compared to content above the fold.

Below is an example of how different zones of a page may be prioritised for an e-commerce website:

Wireframe of a fictitious e-commerce website. Page zones are numbered, giving an example how progressive rendering prioritises different parts of the page over each other. For example, a header is more important than a footer

Page zones are numbered, giving an example how progressive rendering prioritises different parts of the page over each other. For example, a header is more important than a footer

Progressive rendering gets key information back to the user quicker , rather than them having to wait for the entire page to be ready. This was exemplified by a study conducted by UIE, which found:

About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds).

The Truth About Download Time by Christine Perfetti and Lori Landesman

In this example, Amazon appeared quicker to users because information was displayed to the user sooner. It prioritised what the user could see first, and what was most important to the user.

5. UI Skeleton

This technique is closely related to what was just covered, progressive rendering, and is also known as a ‘ghost screen’. The first thing it displays to the user is the page framework; rather like a blank template. This ‘blank template’ is what distinguishes it from plain progressive rendering. Polar, a polling service, uses this very technique:

Parts of the template filled in overtime, once the information is made available by the server.

Parts of the template filled in overtime, once the information is made available by the server.
Image modified from Mobile Design Details: Avoid The Spinner by Luke Wroblewski.

The left-most screen is made up of a set of placeholders. Those placeholders are then gradually filled once the content is made available to the user interface, as the screens to the right depict.

6. Acknowledging Clicks

When pressing the play button on a cassette player, very explicit feedback was given to the user. The button sank lower, and a click sound was heard due to its mechanical nature. This all happened within a very short period of time, due to it being mechanistic in nature.

In software design, the artefacts users interact with are virtual, they are pixels. Good design traits, such as acknowledging interaction must be programmed into those entities.

Acknowledge all button clicks by visual or aural feedback within 50 milliseconds.
First Principles of Interaction Design by Bruce Tognazzini

Tabs on the web are a key example where prompt visual feedback needs to come into play. Even if the tab's content is not yet present, ensure the click/tap is acknowledged within 50ms. You achieve this by styling the tab invoked to active and the previously tab to inactive. Should the content not yet be available, then display a progress indicator, or perhaps offer a distraction, should the request be notoriously long.

You can also apply styling to buttons to indicate something is happening. A good design practice is to also trap multiple clicks of the button, so that the request the button triggers only gets registered once. This will help with speed too.

Jakob Nielsen has written about the 3 different response time limits, which is well worth a read.