One of the biggest challenges in web design and development is building sites fast enough to meet user demands. We face a constant battle of delivering richer content and experiences in a way that doesn’t leave users waiting around for things to happen. There’s nothing worse than staring at a blank screen and this is where so many designers rely on spinners, progress bars and other animations to give users feedback.
However, a new trend has gained a lot of traction over the last couple of years – using “skeleton screens” to quickly load the template of a page and progressively add content as it downloads. Could this be the answer to our loading time problems or are we missing the point when it comes to optimizing for performance?
Skeleton screens in action
Skeleton screens aren’t exactly new and you’ll almost certainly have seen some of these in action. The most famous example has got to be Facebook and we’ve all seen something like this when opening the mobile app:
So a skeleton screen loads the basic layout of a page or app, using placeholders where content and other UI elements belong. Then you’ll typically see a bit of lazy/progressive loading fill the screen with content.
The idea is to show users that a page or application is loading in a way that gradually delivers the content, rather than making them wait for every image, headline and other elements to display. This progressive feedback, in theory, creates the illusion that pages and content are loading faster.
In the image above you see can how the skeleton loads first, before the text content and, finally, the image and social icons appear. This gradual loading gives users something to digest in the way of text content while more resource heavy items are being downloaded.
Without using this technique, users would typically have to wait until the image and those social icons (notoriously slow) to finish downloading before they could engage with the page.
How are skeleton screens better than spinners, progress indicators?
A user never wants to sit there waiting for a blank screen to load, without any hint that things are actually happening. Imagine someone who’s just typed in their credit card detailed and clicked the buy button, only to be greeted by an empty page. They’re wondering if the delay means their payment has been rejected or if they entered their details incorrectly. Should they refresh and try again? If they do, will they end up being charged twice?
These kinds of questions aren’t something any user should be asking themselves – whether they’re paying for something or sending a general enquiry message. Which is where the concept of spinners and progress indicators originally came from. They, at least, give users an indication that something is happening but there are some problems with these solutions as well.
The problem with spinners
The main problem with spinners is they don’t give enough feedback to users. While they confirm that things are running in the background, spinners give no indication of how long users have to wait. This is fine for very brief pauses but anything longer will leave users wondering what’s going on.
The problem with progress indicators
For longer pauses, where spinners don’t provide enough feedback, progress indicators are the next step in UX solutions. The idea is to show users that things are loading and give them idea of how much longer they’ll have to wait.
Of course, most progress bars – especially for websites and mobile apps – are animations and nothing else. They don’t really tell users how much progress has been made, but this is the impression they’re supposed to give.
So the fact that progress indicators are a bit of a lie could be seen as a problem. But, from a purely UX perspective, they leave users sitting there with nothing to do while resources load. Which is a bit of an issue when we’re using these as the go-to solution for longer delays.
Skeleton screens to the rescue?
Skeleton screens aim to solve the problems of spinners and progress bars by progressively loading the content of a page/application. By loading the template of a page first, users can see that progress is in motion without the need for any animations.
More to the point, as content progressively loads users have something to engage with – headlines, content snippets and, eventually, images and other more resource intensive content.
This is where skeleton screens create the impression of speed by breaking up the waiting process. Your pages aren’t actually loading any faster but progressively loading your content keeps users occupied while your bulkier resources are downloading. Those split seconds can be better spent reading headlines and other pieces of text while bulkier resources load.
Sounds like a win-win, doesn’t it?
Are there any problems with skeleton screens?
Skeleton screens are a step forward in terms of creating a more immersive waiting experience for users. Is it the perfect solution? Well, no, of course not – and there are still times (micro interactions) when a spinner or progress indicator will be the better option.
More to the point, what they don’t solve is the much larger issue of websites and applications being too slow for the average user.
The existing culture of relying on bulky frameworks means very few of the sites and applications are built in the most efficient way. The result is loading times and generally slower operation than would otherwise be possible by developing custom applications from scratch.
Skeleton screens and other tricks may cover up some of the cracks of building slow applications but they don’t tackle the root of the problem.
