A Bone to Pick with Skeleton Screens

In the fight for the short attention span of our users, every performance gain, whether real or perceived, matters. This is especially true on mobile, where despite our best efforts at performance, a spotty signal can leave users waiting an interminable few seconds (or more) for content to load.

Design’s conventional answer to unpredictable wait times has long been the loading spinner; a looping animation that tells the user to “Hold on. Something’s coming,” whether that something is one or ten seconds away.

More recently, a design pattern known as progressive loading has gained popularity. With progressive loading, individual elements become visible on the page as soon as they’ve loaded, rather than displaying all at once. See the following example from Facebook:

In the Facebook example above, a skeleton of the page loads first. It’s essentially a wireframe of the page with placeholder boxes for text and images. 

Progressive loading with skeleton screens is thought to benefit the user by indicating that progress is being made, thereby shortening the perceived wait time. Google, Medium, and Slack all use skeleton screens to make their apps feel more performant.

So, should we all be using skeleton screens to make our apps feel faster? To answer this question, we decided to do some lean research into the effects of different loading techniques on perceived wait time.

Test Design

We created a short test for mobile devices that measured users’ perceived wait time for three different loading animations of identical length: a loading spinner, a skeleton screen, and a blank screen.

The quickest way to build the test was to use animated GIFs to simulate each loading animation and put them inside an existing testing framework. (We chose Chalkmark by Optimal Workshop.) Users who opted into the test from a mobile device were asked to complete a simple task and then randomly shown one of the GIFs. Following the task, which was a red herring, they were asked a series of follow-up questions about how long they waited for the page to load.

Follow-up questions:

1. Based just on what you can recall, please respond to the following statement: “The recipes loaded quickly for me." [Strongly agree, Moderately agree, Neutral, Moderately disagree, Strongly disagree, I didn’t notice]

2. From what you can remember, estimate the amount of time it took for the meals to load. [1 second, 2 seconds, 3 seconds, 4 seconds, 5 seconds]

We also measured the time it took users in each group to complete the red herring task. Based on some of the literature we’d read, it seemed plausible that a skeleton loader might actually speed up task completion by orienting users more quickly to the structure of the page.

Roughly half (70) of the participants were sourced through Amazon Mechanical Turk and paid for their participation. The rest were organically sourced through Viget’s social channels. The results were replicated across both groups of participants.

Hypotheses:

1. Users in the skeleton screen group will perceive the shortest wait time.

2. Users in the skeleton screen group will complete the task most quickly.

Results

We gave the test to 136 people, and the skeleton screen performed the worst by all metrics. Users in the skeleton screen group took longer to complete the task, were more likely to evaluate their wait time negatively (by answering the first question with “Strongly disagree” or “Moderately disagree”), and guessed that the wait time had been longer than users who saw the loading spinner or a blank screen.

Table 1. Test Results

	Skeleton screen	Loading spinner	Blank screen
Number of participants	39	39	58
Percentage who agreed with the statement, "The meals loaded quickly for me."	59%	74%	66%
Percentage who disagreed with the statement, "The meals loaded quickly for me."	36%	10%	26%
Average perceived wait time (seconds)	2.82	2.41	2.29
Post-load task completion time (seconds)	10.54	9.49	9.50

Participants in the loading spinner group were most likely to evaluate their wait time positively (by answering the first question with “Strongly agree” or “Moderately agree”) and had a shorter average perceived wait time than those in the skeleton screen group.

Analysis

The unexpectedly weak performance of the skeleton screen may be due to one or more of the following reasons:

1. Skeleton screens are somewhat novel and attract more attention than the ubiquitous loading spinner.

2. Skeleton screens work better in familiar interfaces and can be off-putting in new settings when users don’t know what to expect.

3. Skeleton screens work best when wait times are very short.

Our hunch is that each of these reasons has some merit, but more testing is needed to know for certain. Either way, skeleton screens aren’t a silver bullet for increasing perceived performance and should be used thoughtfully.

Have you implemented or experienced skeleton screens in the wild? We’d love to hear your thoughts. Please leave us a comment.