What Is a Skeleton Screen? Loading Placeholders That Feel Faster

In this guide, Talha Aslan and team walk through skeleton screen design from start to finish. We cover how it differs from a spinner, where it helps, and how to avoid layout shift. We also look at animation, accessibility, and the bad examples we see most often in site audits. Finally, we share a checklist you can apply to your own pages tomorrow.

One quick note first. A skeleton screen does not make your site faster. Your page still takes the same time to load. However, it makes the wait clearer and less frustrating. Knowing this from the start keeps you from designing with the wrong expectations.

How does a skeleton screen differ from a spinner?

A spinner says "something is happening, please wait." It says nothing about what is coming. A skeleton screen says "content with this structure is on its way." In other words, the first only reports a state, while the second reports both state and structure. That sounds like a small difference. Yet it changes the picture visitors build in their heads while they wait.

The Nielsen Norman Group guide to skeleton screens draws this line clearly. According to that guide, skeletons suit full page loads, while spinners fit a single module such as a video player or a dashboard card. For long tasks like file uploads, the guide points to progress bars instead.

The last row deserves its own discussion. We covered when a full screen loading curtain hurts in our post on whether a website should use a preloader. Here, we focus only on skeletons.

Why does perceived performance matter?

Perceived performance is how fast a page feels, regardless of how fast it measures. For example, two pages can load in the same time. One leaves you staring at a blank screen, while the other shows a structure right away. Most visitors feel the second one is faster, because the wait is not a mystery.

Uncertain waits are annoying because nothing explains them. Visitors cannot tell whether the page froze or the connection dropped. So they reach for the back button. A skeleton screen reduces that doubt. As a result, visitors move their eyes to where content will appear and get ready to read.

On the other hand, perceived performance never replaces real performance. Google's Core Web Vitals rely on real user data. You can find the bigger picture in our guide on what Core Web Vitals are. In short, a skeleton makes a fast site feel smoother. It does not rescue a slow one.

When should you use a skeleton screen?

The rule is simple. If content has a clear layout and takes a noticeable moment to load, consider a skeleton. The Nielsen Norman Group guide notes that waits under about one second need no indicator at all. In fact, a brief flash can feel disruptive. For very long processes, the same guide recommends a progress bar with a time estimate.

In our experience, skeletons work best in these places:

• Product lists and category pages, since the card grid is predictable.
• News and blog feeds, where title, summary, and thumbnail repeat.
• Profile pages, because avatar circle, name line, and info blocks are easy to mimic.
• Dashboards and account screens, where data comes from the server and short waits are common.
• Search results, since the number and shape of rows are known in advance.

By contrast, a static company page that ships its text in the first HTML response needs no skeleton. Therefore, measure whether content actually arrives late before you decide.

How do you draw a skeleton for lists, cards, and profiles?

In practice, each page type has its own skeleton. The shared principle is this: the skeleton should be a simple shadow of the real content. Nothing more, nothing less.

On a list page, you draw a square image area on the left of each row and two or three horizontal bars on the right. The first bar stands for the title, so it is thicker. The bars below represent summary lines. Keep the last one a little shorter, because real paragraphs rarely end on a full line.

In a card grid, you draw the whole card. Put an image block at the top, a title bar below it, and a short bar for price or date. For instance, if the real card image uses a 4:3 ratio, the skeleton block should use 4:3 too.

On a profile page, use a circle for the avatar and a medium bar for the name. Add stat boxes underneath. That way visitors understand how to read the page before the details arrive.

Can a skeleton screen cause layout shift?

If you build it right, no. If you build it wrong, yes, and badly. CLS (Cumulative Layout Shift) measures how much page elements move unexpectedly. According to the web.dev explanation of CLS, a score of 0.1 or less counts as good.

The problem starts when you draw the skeleton at one size and the real content arrives at another. For example, the skeleton card stands 200 pixels tall, but the real card comes in at 320 pixels. Everything below jumps down, and the line the visitor was reading moves away. Consequently, the skeleton becomes the cause of the shift instead of the cure.

We explained the technical side and other causes in our post on what CLS is and how to fix it. Here we cover only the part specific to skeletons: matching sizes.

How do you match skeleton size to real content?

Above all, the skeleton must reserve exactly the space the real content will take. We use a few practical methods.

1. Give image areas a fixed aspect ratio. Then the box does not grow when the image arrives.
2. Match text bar height to real line height. Bar plus gap should equal font size plus line spacing.
3. Estimate list length. If the server usually returns 12 products, draw 12 skeleton cards, not 4.
4. Set a minimum height for variable content. Base it on the average of real data.
5. Build the skeleton as the loading state of the real component, not as a separate component. That way it updates whenever the design changes.

The last point gets missed most often. Separate skeletons drift away from the real component over time. Three months later, someone redesigns the card. The skeleton keeps the old size, and the shifting begins.

What should skeleton screen animation look like?

You often see a soft shimmer sliding from left to right, or a slow pulse in tone. This motion reinforces the message "still loading, not stuck." However, Nielsen Norman Group advises using animation sparingly, since it can distract users and create accessibility problems.

We recommend this balance:

• Keep the shimmer slow and low in contrast, so it does not tire the eyes.
• Let all cards shimmer in the same rhythm, because a scattered rhythm feels restless.
• Stop the animation and leave static gray boxes when the user has turned on reduced motion in their system settings.
• Animate only GPU friendly properties such as transform and opacity, and avoid properties that trigger layout.

That last point concerns performance. A heavy animation keeps the main thread busy and can slow down responses to input. In other words, the thing you add to ease the wait should never make interaction slower.

What accessibility rules apply to a skeleton screen?

A blind user browsing with a screen reader does not see gray boxes. So the skeleton needs extra information to say anything to them. Otherwise the screen reader either says nothing or reads empty elements one by one.

This is where the aria-busy concept comes in. The MDN reference for aria-busy explains that this state tells assistive technology an element is still changing. As a result, assistive technology waits until loading ends before announcing changes. You mark the region as busy while it loads and clear the flag once content arrives.

We also apply these steps:

• Hide decorative skeleton boxes from assistive technology, so nobody hears them one by one.
• Add a short "content loading" message that only screen readers announce.
• Do not force focus to move when content arrives. Let users stay where they were.
• Keep skeleton contrast gentle, but not so dark that people mistake it for real content.

For the broader standards, see our guide on web accessibility and WCAG.

Does the WCAG rule on moving content affect skeletons?

Partly, because scope matters. The W3C Understanding document for Pause, Stop, Hide covers moving content that starts on its own, lasts more than five seconds, and appears alongside other content. Users need a way to pause, stop, or hide it. The same document notes that a loading animation that is the only content on the page can fall outside that scope.

However, skeletons usually cover only part of a page. For example, the header and title are ready while the product list below shimmers. In that case, the animation sits next to other content. Therefore, stopping the shimmer or switching to static boxes when loading drags on is a safe choice.

Our practical rule: within a few seconds, the animation either ends or freezes. That way you avoid tiring users and stay close to the standard.

Which bad skeleton screen examples backfire?

In the sites we audit, we often find skeletons that fail or even hurt. Here are the most common mistakes:

1. Mismatched layout. The skeleton shows a three column card grid, but the page arrives as a single column list. Visitors see two layouts and get confused.
2. Endless skeleton. The request fails, yet the skeleton stays. Visitors wait forever and never see an error.
3. Flash on fast loads. Content arrives very quickly, so the skeleton blinks for an instant.
4. Skeletonizing everything. Ready elements like the menu, logo, and footer also turn gray. The page looks empty for no reason.
5. Aggressive shimmer. A bright, fast light wave strains the eyes.
6. Wrong count. The page draws eight skeleton cards, two products arrive, and the page suddenly shrinks.

Most of these show up after development, not during design. That is why you should always test skeletons on a throttled connection.

Why is a frame only skeleton a weak choice?

Nielsen Norman Group describes three skeleton types. First, one type mimics static content and images. A second type adds animation. A third type shows only the frame: header, footer, and background, with no hint of content structure.

We therefore do not recommend the third type. It skips the structural information that gives skeletons their value. Moreover, if the wait runs long, the page looks broken. Visitors face a template with an empty middle and may think the site crashed.

Instead, show at least a few realistic draft lines in the content area. Then visitors know what to expect.

How is a skeleton screen different from an empty state?

A skeleton says "content is coming." An empty state says "there is no content here yet." Mixing them up is a frequent mistake. For example, if a user's cart is empty, you should remove the skeleton as soon as the response arrives and show a clear empty state message.

Otherwise visitors keep staring at gray boxes and think they are still waiting. That is a variant of the endless skeleton bug. So define three exits for every skeleton:

• Content arrived. The skeleton gives way to real content without any shift.
• No content. In this case the skeleton disappears, and a short explanation plus a next step button appear.
• Error. Here, too, the skeleton disappears, and a plain error message with a retry option shows up.

Drawing these three states in the design file from day one removes the scenarios teams forget during development. It also answers the question "when does the skeleton end?" for everyone.

How long should a skeleton screen stay visible?

A skeleton stays until content arrives, but both extremes need care. The first is very short loads. If content arrives within a few hundred milliseconds, skip the skeleton or show it after a short delay. Otherwise it flashes.

The second is long loads. If a request takes longer than expected, add a small status message next to the skeleton. After a set time, switch to an error state. For example, the page could show "Content could not load, try again."

We do not tie these thresholds to a fixed number, because your own data should decide. Look at real user measurements and see how long the skeleton actually stays on screen.

How do skeletons work with images and lazy loading?

Images often arrive last, so they matter most. Therefore, the image area is the most important part of any skeleton. A fixed ratio box holds the space until the image arrives. When it does, the box fills and nothing moves.

With lazy loading, offscreen images load as users scroll. The same logic applies: give image areas a size in advance. We covered the SEO and speed effects in our post on what lazy loading is.

On the other hand, never lazy load the largest image on the page, usually the hero at the top. If that image arrives late, the skeleton lingers and your largest contentful paint gets delayed too.

Does a skeleton screen affect SEO?

Indirectly, it can, so it deserves attention. The skeleton itself is not a ranking factor. However, a poor setup hurts CLS, and CLS is one of the page experience metrics.

A bigger risk involves content visibility. Some sites fetch all content with JavaScript in the browser, so the first HTML contains only the skeleton. With that setup, search engines may struggle to reach the content when they process the page. So a sturdier approach is to render important text on the server and use skeletons only for parts that truly arrive late.

In short, a skeleton screen is a user experience tool. On the SEO side, your job is to make sure it never hides content or shifts the layout.

How should text bars reflect real content density?

Also, bar length is a small but powerful detail. If every line has the same length, the skeleton looks artificial. Real text ends at different points, so keeping the last line short looks more natural.

Next, make title bars thicker and shorter than body bars. For instance, a card title usually takes one or two lines, while a summary runs two or three. When the skeleton reflects that ratio, visitors read the hierarchy before content arrives.

At the same time, avoid too much detail. Drawing a gray box for every icon, badge, and tiny label clutters the skeleton. Show the main blocks and skip small ornaments. In short, a skeleton is a sketch, not a copy.

The same simplicity applies to color. One neutral gray and a slightly lighter shade cover most designs. On dark themes, pick a tone a little lighter than the background, so the skeleton stays readable in both themes.

How should skeletons behave during page transitions?

On sites built like single page apps, clicking a link does not reload the page. Only the content area changes. Skeletons help a lot here, because users immediately see that their click registered.

The web.dev CLS article touches on this too. Expected changes right after a user interaction do not count as a problem. In fact, showing a loading indicator right away beats shifting content when a request finishes. So showing a skeleton immediately after a click is a safe move for layout stability.

Still, wiping old content and returning to a skeleton is not always right. For example, when a filter changes, fading current products and adding a small indicator on top feels less jarring than turning the whole page gray. Make that call based on how people use the page.

How do you document the skeleton in a design system?

On sites with many page types, leaving skeletons to each team member's interpretation creates inconsistency. That is why we suggest documenting the skeleton as a separate state in your design system. Every component should also define its loading state.

Include the following in that document:

• Skeleton color, with separate values for light and dark themes.
• Corner radius, identical to the real component.
• Text bar height and line spacing.
• Animation speed, direction, and how it stops under reduced motion.
• How many skeleton items to draw and where that number comes from.
• What appears in empty and error states.

With this in place, developers do not invent skeletons from scratch for each new page. They follow the existing rule. Example scenario: a blog redesigns its post card, and thanks to the document, the skeleton card switches to the new size on the same day. The shift risk disappears before it starts.

Who should build your skeleton screen?

A skeleton is a component that designers and developers should decide on together. Designers set layout and tone. Then developers handle sizes, states, and accessibility flags. When the two work apart, the mismatches above appear.

Example scenario: an online store wants skeletons on its category page. The designer draws a slick shimmer in Figma. Meanwhile, the developer codes the skeleton as a separate component with a fixed count of four cards. As a result, four cards appear first, then twelve arrive and stretch the page. A shared plan would have prevented this from the start.

If you want this part built right from day one, our web design service plans loading states, error screens, and the sizing system together.

How do you test a skeleton screen?

First, the easiest way is to throttle the network in your browser's developer tools. Then you see the skeleton for several seconds and can watch the switch to real content. If anything moves during that switch, you have a size mismatch.

We also recommend these tests:

1. Check mobile and desktop widths separately, since the skeleton must be right at every breakpoint.
2. Force the request to fail and check the error state.
3. Open the page with a screen reader and listen to what it announces.
4. Turn on reduced motion in your operating system and confirm the animation stops.
5. Compare CLS in real user data before and after launch.

Do not leave testing to one person. Designers should check layout, developers sizes and states, and content owners whether text lengths are realistic. For example, real product names are often longer than the sample name in the design file. Consequently, testing with real data always beats testing with sample data.

These tests take a few hours. Still, that costs far less than a shift nobody notices in production, annoying users for weeks.

Is a skeleton screen right for every site?

No, and that is fine. Specifically, on pages with little content that the server renders quickly, a skeleton is an unnecessary layer. For example, on a one page brochure site, text and images already arrive with the first load. Adding a skeleton there only brings extra code and maintenance.

By contrast, skeletons are valuable on data heavy pages that update often or change per user. Dashboards, product lists, inboxes, and search results all belong in this group.

Ask yourself one question: is the visitor waiting for something right now, and does that something have a layout? If both answers are yes, a skeleton is worth considering. If you want to explore other common interface problems, our post on UX mistakes that kill sales is a good next read.

Should we build skeleton loading into your site together?

At first glance, a skeleton screen looks like a small detail, so teams often skip it. Done well, it calms the waiting moment. Done badly, it shifts the page and erodes trust. Sizing, error states, animation balance, and accessibility all belong to one plan.

At Talha Aslan and team, we treat loading states as part of the design from day one, both on new sites and redesigns. If you would like us to build this for your list, card, or dashboard screens, you can request a quote through our web design service page. We review your page types and prepare a proposal with the scope and timeline that fit your site.