Skeleton Screens vs. Spinners: Designing Loading States for Real UX

1. Loading States as Part of the User Experience

Every asynchronous operation, whether a page visit, an API request, or an image load, inevitably creates a gap between the user's action and the visible result. How that gap gets filled noticeably determines whether an application feels responsive or sluggish, independent of the actual measured load time in milliseconds. A spinner and a skeleton screen solve the same technical task but differ clearly in their effect on perceived wait time.

A spinner merely signals that something is happening, without any information about the incoming content. A skeleton screen, on the other hand, already sketches the rough structure of the upcoming content, say placeholders for a heading, an image, and text lines, conveying a concrete expectation. This structural preview is the central difference that makes skeleton screens superior for longer or predictable load times.

2. Perceived Versus Actual Load Time

User research on wait times has shown for decades that the felt duration of a wait depends more on predictability and provided occupation than on the raw measured time. A skeleton screen exploits exactly this effect: because the future page structure is already visible, the loading process feels like a page build already underway rather than an undefined black box, making the same objective wait time feel subjectively shorter.

A spinner, by contrast, provides no progress information at all, every second feels just as undefined as the last, which leads to noticeable impatience especially beyond roughly one second of loading. For very short wait times below that threshold, the difference barely matters, since the loading state is hardly consciously registered before the content already arrives.

3. When a Spinner Remains the Better Choice

For punctual, short actions like submitting a form, a button click, or a single API mutation, a spinner remains the more fitting solution, because no predictable page layout exists here that a skeleton could meaningfully sketch out. A spinner directly inside a button, accompanying a load typically under two seconds, communicates clearly and without unnecessary effort that the action has been accepted and is in progress.

For completely unpredictable load times too, say uploading a large file with heavily fluctuating network speed, a static skeleton would be misleading, because it suggests a structure that may not be filled for quite a while. A spinner, ideally combined with a textual status like a progress percentage, stays more honest here than a skeleton implying imminent completion.

function LoadingButton({ isLoading, children, ...props }) {
  return (
    <button disabled={isLoading} aria-busy={isLoading} {...props}>
      {isLoading ? (
        <span className="spinner" role="status" aria-label="Loading" />
      ) : (
        children
      )}
    </button>
  );
}

4. When a Skeleton Screen Wins

Once a page or a page section has a known, recurring structure, say an article list, a user profile, or a product card, a skeleton screen delivers real value, because the placeholders anticipate exactly the later arrangement of image, title, and text. Users immediately recognize what kind of content this is, even before the actual data arrives, which considerably eases orientation.

Skeletons also work great for initial loads of entire page sections inside a single-page application, say when switching between routes, because they additionally improve the Cumulative Layout Shift score: since the placeholders already occupy the same space as the later content, no abrupt layout jump occurs once the real data appears, unlike a spinner that typically floats centered in an empty area.

function ArticleCardSkeleton() {
  return (
    <div className="card" aria-hidden="true">
      <div className="skeleton skeleton-image" />
      <div className="skeleton skeleton-line" style={{ width: "70%" }} />
      <div className="skeleton skeleton-line" style={{ width: "90%" }} />
      <div className="skeleton skeleton-line" style={{ width: "40%" }} />
    </div>
  );
}

5. Skeletons as a Suspense Fallback

React Suspense provides the natural hook for using skeleton screens in a structured way, instead of threading manual isLoading flags through an entire component. A data component that suspends during render, say because it loads through a cache or a Suspense-enabled data library, can be wrapped directly with the matching skeleton as its fallback, with no extra state for the loading condition at all.

This approach has a practical side benefit: the skeleton fallback can be tailored exactly to the structure of the component in question and lives right next to it in the code, instead of being defined as a generic, reused spinner somewhere central. For lists with multiple cards, it also helps to render several skeleton instances as the fallback, so the page roughly hints at the eventual list length even while still loading.

function ArticleList() {
  return (
    <Suspense
      fallback={
        <div className="grid">
          {Array.from({ length: 6 }).map((_, i) => (
            <ArticleCardSkeleton key={i} />
          ))}
        </div>
      }
    >
      <ArticleGrid />
    </Suspense>
  );
}

6. Content-Aware Skeletons Instead of Generic Bars

A common mistake with skeleton screens is using a single, generic gray rectangle for every content type. More effective are skeletons that mirror the actual text structure: differently sized lines for headline and body text, a circular placeholder for an avatar image, a row of short lines for metadata like date or author. This differentiation considerably raises the perceived accuracy of the preview.

It matters to base skeleton widths not on pure randomness but on typical, realistic text lengths, say 60 to 90 percent width for headlines and varying values for body text lines, so the transition to the real content feels as unobtrusive as possible. A placeholder that is too wide or too narrow compared to the actual text otherwise creates a small but noticeable jump when the real data appears.

7. Accessibility for Both Approaches

For screen reader users, a purely visual loading state without semantic markup is worthless. A spinner should therefore carry role="status" together with an aria-label or hidden text, so screen readers explicitly announce the loading state. A skeleton screen, in turn, should be hidden from screen readers via aria-hidden="true", since the placeholder elements themselves carry no meaningful information and would otherwise be read out as meaningless empty elements.

The surrounding container that switches between skeleton and real content additionally benefits from aria-busy="true" while loading, so assistive technology knows the region is still being built. Once the actual content appears, aria-busy should switch to false, and if the update happens outside the user's direct focus, an aria-live region should additionally announce the completion of loading unobtrusively.

function ContentRegion({ isLoading, skeleton, children }) {
  return (
    <div aria-busy={isLoading}>
      {isLoading ? <div aria-hidden="true">{skeleton}</div> : children}
      <span className="sr-only" aria-live="polite">
        {isLoading ? "" : "Content loaded"}
      </span>
    </div>
  );
}

8. Combining Skeleton and Spinner

In many applications, both patterns complement each other across different loading phases rather than being mutually exclusive: the initial page build uses a skeleton screen to sketch out the rough structure, while subsequent actions within the same page, say loading more entries via pagination or infinite scroll, use a small, unobtrusive spinner at the bottom of the list.

This combination follows the logic that a skeleton makes sense when the layout is already visible but still empty, while a spinner fits better on an already filled page to which new content is merely being appended and whose structure is not yet known. A full skeleton for every single newly loaded card would feel more restless than helpful here.

9. Measuring the Effect Instead of Just Assuming It

Whether a skeleton screen actually improves perceived performance cannot be derived from theory alone, it should be measured on a per-project basis. Meaningful signals include the bounce rate during loading, qualitative user surveys about felt wait time, and A/B tests that ship the same load time once with a spinner and once with a skeleton and compare the resulting interaction rate.

Technically, the effect can additionally be verified through Core Web Vitals metrics like Largest Contentful Paint, since an overly elaborate skeleton with many animations can paradoxically contribute to delaying the actual content paint itself. The recommendation is therefore to keep skeletons deliberately lean and regularly re-check the effect against real usage data instead of relying on a one-time design decision.

10. Summary

11. FAQ: Skeleton Screens vs. Spinners: The Essentials at a Glance