Design & UX
By Chris Lienert

How to Speed Up Your UX with Skeleton Screens

By Chris Lienert

However well-designed your user interface may be, at some point or other, the people using it are going to have to wait for something to load.

A 2014 MIT study showed that humans can perceive discrete images in as little as 13 milliseconds however deciding where to focus takes between 100 and 140 milliseconds. In practical terms, this gives us around 200 milliseconds to present a user interface state change in order to appear instant.

Between 200 milliseconds and 1 second, people feel they are within the flow of their actions. After 1 second without any other feedback, focus starts to shift. Beyond 10 seconds, user focus is likely to be lost entirely.

To make people happy, we need to give an indication that something is happening. This leaves us with three basic options:

  • progress bar if we can measure the duration;
  • spinner if we can’t; and
  • nothing at all.

Psychological studies into progress indicators show that our interpretation of them is anything but linear. Our method of processing a delay doesn’t match up with reality.

Understanding this concept leads us into the realm of manipulating interfaces in order to improve perception.

In software design, skeleton screens provide an alternative to the traditional methods. Rather than show an abstract widget, skeleton screens create anticipation of what is to come and reduce cognitive load.

Skeleton Screens in the Wild

Apple have incorporated skeleton screens into their iOS Human Interface Guidelines under the name ‘launch images’. Apple’s guidelines recommend showing an outline of the initial application screen excluding text and any elements that may change.

Apple’s Clock

Apple’s Clock is a classic example of a skeleton screen. The launch screen sets the expectation of what the app will look like and creates an impression of the app loading faster than it actually does.

iOS Apple Clock 1

This launch screen shows the basic outline of the app and the four icons at the base of the screen.

iOS Apple Clock 2

Once launched, the all the text and variable UI elements are filled in.


Nintendo has recently launched their first mobile application which pays absolutely no attention to UI guidelines or common decency.

iOS Miitomo 1

The initial launch screen shows the title of the app and a background image none of which reflect the application’s use.

iOS Miitomo 2

After launch, a load screen first has a “Loading” text indicator as a minimalist spinner,

iOS Miitomo 3

… then a numeric progress indicator,

iOS Miitomo 4

… followed by another spinner,

iOS Miitomo 5

… and finally the application itself.

Over the incredible 14 second load time, Nintendo use 2 spinners and one progress bar none of which do much to ease the load time. The dynamic “tips” during the load screen also act as a spinner by changing the UI state and creating a sense of progress.

Each discrete screen requires a new visual scan and makes the launch process seem even slower than it actually is.


While Nintendo gets it very wrong, Facebook gets it very right.

iOS Facebook

Their initial launch screen follows Apple’s guidelines.

iOS Facebook 2

Having met the goal of the initial guidelines, Facebook now populates more of the screen with the header, footer and placeholder images in the body. Because the time taken to load the final content is unknown, there is also a subtle animation on this screen in place of a spinner.

iOS Facebook 3

The final UI is loaded.


Making it Happen

Looking at the examples above, you may have noticed that the images used aren’t drastically different from wireframes. It’s in this observation that a lot of the work may already be done for you.

In this demonstration, we’ve identified that the initial load is taking longer than we’d like so it’s time to add skeleton screens to improve the perceived load time.

Demo 1

Here’s our initial wireframe showing the screen layout.

Demonstration first skeleton screen

On initial rendering, only the header and a reserved space for the content are shown

Demonstration second skeleton screen

While we’re waiting, the image from the wireframe is shown.

Demonstration third skeleton screen

Next, the text is rendered while we wait for the images

Demonstration final loaded screen

The final rendered content is shown.

By progressively rendering each component, the wait seems shorter.


Skeleton screens can improve the feel of any action taking longer than a few hundred milliseconds. Applying them to your rendering bottlenecks will make your UI feel faster and make people happier.

  • M S i N Lund

    I have seen this on some sites lately.

    It always makes them look slower and more broken.
    More like a shitty phone-app than a real website.

    Whenever something appears on the page, you tend to look at it and start to try to make sense if it.

    -Hmmm, i guess that gray thing is an …icon, maybe i should try clic…

    …then while you are doing that, its replaced with something else, and then other things keep changing and dancing all over the place.

    Its exhausting, like your mind is forced trough a series of repaint-events.

    Perhaps this works better in phone-apps, I haven’t noticed since I rarely use those things, but it definitely sucks for websites.

    • Chris Tiearney

      I actually think it could be very cool for websites, but has to be implemented correctly. The mere fact that you were guessing what that grey thing is, tells me its not implemented correctly. Giving visual feedback is great with these skeleton wireframes, but with something indicating to the user that pieces of the skeleton are loading might make it better?

      • M S i N Lund

        I think filler withespace with a normal spinner in it, does the job.

        It keeps things from dancing around, and signals more stuff is coming but not ready.

        If you are using a placeholder, it better:
        1.) Not look like content.
        2.) Not look like something that has finished loading.

        • Malachi

          And why having placeholders for text? I mean.. text. What makes text load slow? Nothing. So having placeholders for images would be better imho.. and placeholders having a normal spinner would work even better. I’m also not in favor of skeleton screens with placeholder stuff. (and.. the placeholder stuff has to load as well…)

          • M⃠ ⃠S⃠ ⃠i⃠ ⃠N⃠ ⃠L⃠u⃠n⃠d⃠


            Last time I had to sit and wait for individual lines of text to load, was back in the 90’s.

            And now that shit is back again,
            thanks to idiot designers and script-kiddy coders jumping on every stupid trend that is put in front of them.

          • John_Betong

            Google has refined this rapid loading process by offering free cached pages to all AMP validated pages. They claim rendering in less than a second!


          • M⃠ ⃠S⃠ ⃠i⃠ ⃠N⃠ ⃠L⃠u⃠n⃠d⃠

            Oh you mean Googles attempt to replace the web with shitty google-apps designed by a company that knows nothing about usability and web design?

            Yeah, I cant want to take bigger and bigger bites out of that shit-sandwich.

  • Henry

    How is showing a couple of relatively simple apps (clock and text/thumbnail-content-cards) an appropriate comparison to the nintendo app, which displays a 3d environment.

    You need to use an appropriate comparison to reinforce your point. How about showing another 3d environment app / game which does loading right, rather than an incredibly simple interface?

    I’m not sure the clock is even a reasonable example. It doesn’t show a skeleton for any of the actual content… it’s simply loading a navbar first…

    Yeah, a good loading process is nice, but this article lacks any real consideration or understanding of the challenge.

  • Tekeste Gebreanenia

    How can I create this with CSS?

    • I’m working on an open-source library to tackle this. You’d need a combination of CSS and JavaScript to pull it off.

Get the latest in Design, once a week, for free.