012 min
How Polar replaced spinners with skeleton screens
In 2013 Polar was a young mobile app built around small, quick interactions. Parts of its interface were web pages loaded inside the native app, and each page took a moment to download. To show that something was happening, the team put a spinner on screen while each page loaded. People met these spinners in several parts of the app. Soon users wrote in to say the new version felt slower than the old one, with too much waiting for pages to load.
Luke Wroblewski, who was building Polar at the time, wrote about the problem in a September 2013 post called Mobile Design Details: Avoid The Spinner. His argument was simple. A progress indicator exists to tell someone they must wait. So it pulls attention to the waiting itself, and a wait that gets attention feels longer. The spinner had not slowed the app down. It had made people notice every delay.
The team's answer was to show each screen's layout first and fill it in. Wroblewski described the technique in one sentence: "A skeleton screen is essentially a blank version of a page into which information is gradually loaded." Polar used skeleton screens in several places and removed its spinners. Polar filled each screen in three stages: grey boxes with borders and headings first, then the text, then the images.
Wroblewski's post is the description most guides trace the pattern back to, and it does not claim to have invented the name. The skeleton screen is practitioner convention, not a research finding. One team found a fix that its users liked. The controlled studies came later, and they do not all agree.
022 min
How a skeleton screen changes the feel of a wait
A skeleton screen leaves the real loading time exactly where it was. The data takes as long to reach the phone as before, and the latency of the network does not change. What changes is what the person does while they wait.
Tim Kadlec, who writes about web performance, explained the effect in 2020 with two kinds of waiting. In a passive wait there is nothing to do but look at an indicator that has nothing to do with the coming content. A spinner makes the whole wait passive. In an active wait, the person is doing something that feels like progress. Kadlec cites time-perception research finding that active waits feel shorter than passive ones.
A skeleton screen turns parts of the wait active. Each time the screen changes, from grey boxes to headings to text, the person has something new to take in: where the headline sits, how many items there are, where the pictures will go. Each change gives a short moment of attention to the content instead of the delay.
The layout also tells people where to look. Nielsen Norman Group argues that the wireframe-like page lowers cognitive load, the mental effort of making sense of a screen, because users already know the page's structure when the content arrives. This is one way to meet the heuristic of visibility of system status. The screen shows that the system is working, and also what it is working on.
Some guides add the Zeigarnik effect, the tendency to remember unfinished tasks better than finished ones, as a reason a half-filled screen holds attention. That link is a guess. The studies of skeleton screens measured how long the wait felt, not what people remembered.
Why a skeleton screen cannot say how long
In 1985 David Maister, writing about queues in banks, restaurants and offices, listed rules for how waits feel. One of Maister's rules is that an uncertain wait feels longer than a wait of known, finite length. A skeleton screen removes one uncertainty: what is coming and where it will appear. It removes nothing about the other one, which is how long the wait will last. That is the main reason the pattern suits short waits and fails long ones.
032 min
The three types of skeleton screen
Skeleton screens differ in how much of the page they draw and whether they move. Nielsen Norman Group's 2023 guide, written by Samhita Tankala, sorts them into three types.
| Type | What the user sees | Verdict in the NN/g guide |
|---|---|---|
| Static content and image | Light grey boxes and bars where text and images will appear | The most common type; suits full-page loads |
| Animated | The same shapes with a pulse, a fade, or a band of light moving across them | Can help, but motion can distract, annoy or cause accessibility problems |
| Frame display | Only the header, footer and an empty background | Not recommended: on a long wait, users assume the page is broken |
The frame-display type fails because it gives no sense of the page's structure. It looks like a page that failed to load, which is the opposite of what a loading state should say.
Where the shimmer animation came from
Facebook built a shimmer effect to show loading status in Paper, one of its apps. The company then released the code as an open-source library for iOS called Shimmer, and a separate version for Android. The library's own description calls it an unobtrusive loading indicator. The same moving band of light is now a common style for animated skeleton screens.
Why the motion inside a skeleton screen might matter
Motion inside a loading state can change how long the wait feels. In 2010 Chris Harrison, Zhiquan Yeo and Scott Hudson at Carnegie Mellon University tested animated progress bars with moving stripes. Bars whose stripes moved backwards, against the direction of progress, did best. Their best design made a process seem 11% faster without changing how long it took. The study used progress bars, not skeleton screens. It shows that the motion design of a loading state is not neutral. It does not show which way a shimmer should move.
043 min
When a skeleton screen fits the wait
Because a skeleton screen says what is coming but not how long, the length of the wait decides whether it helps. Nielsen Norman Group advises using skeleton screens only for waits under 10 seconds. Its guidance splits waits into three bands.
| Expected wait | What to show | Why |
|---|---|---|
| Under 1 second | Nothing, or the content directly | A skeleton would appear and vanish before it helps |
| 1 to 10 seconds | A skeleton screen for a full page or large section; a spinner for a small part | Users still pay attention, and the layout gives them something to read |
| Over 10 seconds | A progress bar with an estimate of time left | Users need to know how much longer they will wait |
A skeleton screen that shows for a fraction of a second is worse than none. The grey shapes appear and disappear, and the page seems to flicker. Some teams wait a short moment before showing the skeleton, and once it appears, keep it on screen long enough to avoid the flicker.
The pattern also suits some pages better than others. It fits pages built from repeated, predictable blocks: feeds, search results, product grids, dashboards and image-heavy pages. It does not fit a video that is buffering, a file upload or any long process, where the person needs progress, not a layout. IBM's Carbon design system narrows it further. Skeleton states belong on containers of content such as tiles, lists, data tables and cards. Carbon says never to use them for notifications, menus, dropdown items, modals or loaders, and that buttons, inputs, checkboxes and toggles usually do not need one.
Where the 1-second and 10-second limits come from
The bands are older than skeleton screens. In his 1993 book Usability Engineering, Jakob Nielsen summarised limits that went back to work by Robert Miller in 1968 and Stuart Card and colleagues in 1991. About 0.1 seconds feels instant. About 1 second lets a person keep thinking about the task without a break, though they notice the delay. Nielsen put the limit for keeping a person's attention on the task at about 10 seconds. Past that point, people start doing other things while they wait, so they need to know when to come back. The Doherty threshold makes a related claim about how fast a system must respond to keep people engaged.
What a skeleton screen shows when the total is unknown
Nielsen's same chapter covers a case skeleton screens often face. When a system cannot know in advance how much work there is, a percent-done bar is impossible. It can still show running progress as the amount of work done so far. A skeleton that fills one card at a time does exactly this. Each filled card is a unit of finished work, even though the total is still open.
051 min
How skeleton screens show up in real interfaces
With those limits in mind, real products show both good and bad skeleton screens. The difference is rarely the grey shapes themselves. It is how long they stay and how much they say.
Applied: LinkedIn, Headspace and DoorDash
LinkedIn shows a skeleton of its page while content loads, so users see how the page will be structured before any post arrives. Headspace, the meditation app, uses one to set expectations for the structure of its screens. DoorDash uses a short animated skeleton: a shimmer that moves from left to right across the placeholders.
Violated: YouTube in a desktop browser
YouTube shows what happens when the wait is long. Web developer Scott Jehl tested YouTube in a desktop browser, and Tim Kadlec used the result in 2020 as a typical case. On a cable connection, people looked at grey boxes for 6.9 seconds before any content appeared. The page also had only two stages: grey boxes with borders, then everything at once. There were no early headings and no partial content.
Compare that with Polar's three stages. Polar gave people new information at each step, so they kept moving between short active moments. YouTube gave them one look at a grey layout, then nothing new for several seconds. After the first moment of reading the layout, the wait became passive again, and the skeleton did no more than a spinner would.
062 min
Where the evidence on skeleton screens is contested
The YouTube case is a design failure. A 2017 study from the digital agency Viget raised a harder question: whether skeleton screens shorten the felt wait at all.
Kathryn Faulkner and Katherine Olvera built a short test for mobile devices. Each participant did a simple task, then saw one of three loading animations of identical length: a skeleton screen, a spinner or a blank screen. A screen of meals then appeared. The animations were GIFs inside an online testing tool, and the team expected the skeleton to win.
Of the 136 people who took Viget's test, those shown the skeleton screen did worst on every measure. The people who saw the skeleton screen guessed the longest wait, 2.82 seconds, against 2.41 for the spinner and 2.29 for the blank screen. They also took longest on the task after the load, and they were the most likely to say the meals had not loaded quickly.
The authors offered three possible reasons. Skeleton screens were still new, so they drew more attention than a familiar spinner. They may work better in an interface people already know, and feel strange in an unfamiliar one. And they may only help when waits are very short. Their conclusion was that skeleton screens are not a reliable way to improve perceived speed and need careful use.
The study has real limits. It simulated loading with animated GIFs rather than a real app, the groups were unequal (39, 39 and 58 people), and every wait had the same fixed length. Nielsen Norman Group still recommends skeleton screens for full-page loads under 10 seconds, so the two sources disagree on whether the pattern helps.
A second line of criticism is about honesty, not timing. An article on Webdesigner Depot, Skeleton Screens Are Just Gray Lies We Tell Ourselves, argues that teams use skeleton screens to hide slow systems instead of fixing them, and that the effect fades as users grow used to the pattern. Many guides also claim skeleton screens reduce bounce rates, but the evidence they point to is usually about load time itself, not about skeleton screens.
Where this leaves a team: treat a skeleton screen as a possible improvement to test with your own users, not as a proven one. Measure the felt wait as well as the real one, and fix the real wait first.
072 min
Applying skeleton screens
If a team decides a skeleton screen is worth testing, a few design moves decide whether it helps.
Shorten the wait first.
If the content can appear right away, show it. A skeleton screen is a fallback for delays a team cannot remove.
Match the real layout exactly.
Give each placeholder the size and position of the content that will replace it. When the shapes are wrong, content jumps as it arrives. Google's Cumulative Layout Shift metric scores that movement, and a score of 0.1 or less counts as good.
Fill in stages.
Show headings and text as soon as they arrive, and let images come last. Do not hold everything back to reveal it in one step.
Draw only content containers.
Use placeholders for cards, list rows and tables. Leave buttons and form controls out, so nobody tries to use a control that is not there yet.
Keep the look quiet.
Use a pale neutral grey, slow and subtle motion or none, and fade the content in over the placeholders instead of switching at once.
Respect motion settings.
Turn the animation off for people whose device asks for reduced motion.
Test with your own users.
After Viget's result, no team should assume the skeleton helps.
The same reasoning points to alternatives. Lazy loading waits to load images further down the page until the person scrolls near them. Streaming sends the parts of a page that are ready first. Optimistic updates show the result of an action before the server confirms it. Prefetching loads the next page before the person asks for it. Each of these shortens or removes the wait itself.
Skeleton screens as a built-in framework feature
Front-end frameworks now build the pattern in. In Next.js, a file named loading.js gives a route an instant loading state, shown the moment someone navigates to it. Next.js wraps the page in a React Suspense boundary. The server sends the loading state, often a skeleton, while the rest of the page streams in, and swaps in the real content when it is ready. The skeleton is no longer something a team adds at the end. It is a standard part of how the page is built.
Placeholders drawn from the real layout in SwiftUI
Apple's SwiftUI reaches the same pattern a different way. Its redacted(reason: .placeholder) modifier renders the real view with its text masked out in grey. Because the placeholder is built from the actual layout, it cannot differ from it. That removes the most common skeleton failure: a layout that does not match the content.
082 min
Skeleton screens and accessibility
A skeleton screen is a visual signal, so people who cannot see it get nothing from it. A screen reader has no text to read in a grey box. The page should mark the loading region as busy, for example with aria-busy="true", and announce when the content has loaded. WCAG 2.2 Success Criterion 4.1.3, Status Messages, covers this kind of announcement. Placeholders should also not receive keyboard focus, because there is nothing in them to use.
Motion is the second issue. A pulsing or shimmering skeleton can distract people and bother those who are sensitive to motion. The CSS media query prefers-reduced-motion lets a page detect that a user has asked their device for less motion, and the shimmer should stop for them.
When a moving skeleton screen needs a pause control
WCAG 2.2 Success Criterion 2.2.2, Pause, Stop, Hide, sets a rule for motion that starts automatically, lasts more than five seconds and appears next to other content: the user must be able to pause, stop or hide it. The W3C's guidance makes an exception for loading. An animation during a preload phase can count as essential if users cannot interact during that phase and, without it, might think the content had frozen or broken. A full-page skeleton that blocks the page fits that exception. A shimmer on one card that keeps running past five seconds while the rest of the page is usable fits it less clearly.
091 min
How to spot a skeleton screen going wrong
A team can check for these in session recordings, performance tools or support tickets.
- Content jumps when it arrives. The placeholders were the wrong size, and the page's Cumulative Layout Shift score rises above 0.1.
- Grey boxes stay on screen for more than about 10 seconds. The wait is too long for a skeleton. It needs a progress bar or a faster page.
- The skeleton flashes. It appears for a fraction of a second on fast connections, and the page seems to flicker.
- The shape does not match the content. The skeleton shows six cards and three arrive, or a list turns into a grid.
- The skeleton never ends. A failed request leaves the grey shapes on screen with no error message.
- People tap the placeholders. Taps on grey boxes suggest users took them for content or controls.
102 min
Skeleton screen vs. spinner, progress bar and lazy loading
Skeleton screens sit among several loading patterns, and each one answers a different question for the user.
| Pattern | What it tells the user | Best fit |
|---|---|---|
| Skeleton screen | What is coming and where it will appear | Full-page or large-section loads of about 1 to 10 seconds |
| Spinner | That the system is working | Short waits for one small part of the page |
| Progress bar | How much is done and how much is left | Waits longer than about 10 seconds |
| Preloader | That the page is not ready, with nothing else shown | Rarely the best choice, because it hides the layout |
| Lazy loading | Nothing by itself; it decides when content loads | Images and sections further down the page |
The axis that separates them is information. A spinner tells the user working. A skeleton screen tells the user this, here. A progress bar tells the user this much longer. Lazy loading is not a visual signal at all, so it pairs with a skeleton screen instead of replacing it.
The labor illusion is a nearby idea with the opposite aim. In the labor illusion, people value a result more when they can see the work being done for them. A skeleton screen hides the work and shows only the shape of the result. One makes the wait visible on purpose, and the other moves attention away from it.
?4 questions
Questions people ask
Is a skeleton screen the same as a wireframe?
What colour should a skeleton screen be?
How do you build a skeleton screen in code?
Should search results use a skeleton screen?
§14 sources
Sources
Luke Wroblewski, "Mobile Design Details: Avoid The Spinner", LukeW, 17 September 2013.
Kathryn Faulkner and Katherine Olvera, "A Bone to Pick with Skeleton Screens", Viget, 19 October 2017.
Samhita Tankala, "Skeleton Screens 101", Nielsen Norman Group, 2023.
Tim Kadlec, "Effective Skeleton Screens", 2020.
Show all 14 sourcesShow fewer sources
Jakob Nielsen, "Response Times: The 3 Important Limits", Nielsen Norman Group, 1993 (excerpt from Usability Engineering).
David Maister, "The Psychology of Waiting Lines", 1985.
Chris Harrison, Zhiquan Yeo and Scott E. Hudson, "Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations", CHI 2010.
Facebook, "Shimmer", open-source iOS library on GitHub.
IBM, Carbon Design System, "Loading" pattern.
W3C, "Understanding SC 2.2.2: Pause, Stop, Hide", WCAG 2.2.
Google, web.dev, "Cumulative Layout Shift (CLS)".
Vercel, Next.js documentation, "loading.js".
Paul Hudson, "How to mark content as a placeholder using redacted()", Hacking with Swift.
Webdesigner Depot, "Skeleton Screens Are Just Gray Lies We Tell Ourselves".