Skeleton screens in different shapes and sizes are seemingly found everywhere across the web and apps — anywhere humans are forced to wait.
To mitigate focus on the loading process, versus the actual content that is loading, Wroblewski introduced a novel new design pattern — the skeleton screen. In his own words, they are “essentially a blank version of a page into which information is gradually loaded.” These visual placeholders were shown by Wroblewski to be light grey boxes that appeared instantly in areas where content had not yet completed loading.
You have likely seen skeleton screens in action without realizing it. Quite simply, they are content placeholders that are simple shapes filled with a solid color that are visible until the actual content has loaded. Various implementations of them can be seen across major websites like Google, Facebook, YouTube, Slack, Reddit and LinkedIn. They are an intermediary step in the loading process where the structure of the interface is created, but without requiring actual content – that is to say, they are the “bones” of the UI without any “meat” on them.
Skeleton screens reduce the perceived load time by informing the user of what interface to expect as early as possible in the loading process. As they outline the structure itself, they can be hard coded to appear while the server is still collecting and delivering all the page-specific content. Additionally, the user is provided with a sense of progression as the blank screen fills in with the skeleton and then the content, instead of just staring at a loading spinner or blank screen until the content is rendered.
The approach we went with for implementing skeleton loading pages is not to create a separate, dedicated skeleton page but rather a built-in ‘skeleton state’ of a component. This is a more robust and scalable solution that will allow for more flexible loading patterns across different pages.
You are increasing the amount of code you have — your components will need an additional layer of logic to handle what should be rendered and when. This will add a significant amount of code to what was originally a simple React component and could make things harder to debug. Also, as mentioned above, if you decide to use a package, you are adding more dependencies to your codebase, which increases security risks and is less customisable than implementing a simple solution yourself.
Changes to components inevitably mean changes to the skeleton. The method outlined above is robust, however, if you change the layout or add features, you also need to make sure the skeletons are changed to reflect that.
Regardless, the use of skeleton loading pages is everywhere and is quickly becoming the expectation of what the ‘loading experience’ is. As you can see, it’s not hard to do, so give it a go, experiment with different approaches and decide if they are just a trend or if they really do work.