Open a feed app on a weak connection and you get a screen full of gray rectangles for a second or two. Bars where the headlines go, circles where the profile photos go. That’s a skeleton screen, and it has quietly become the default loading state for feeds, profile pages, and search results, anywhere a network request would otherwise leave a blank rectangle staring back at you.
How long should one stay up? IBM’s Carbon design system documentation puts a rough ceiling on it: the skeleton state sits on screen for only a few seconds, then disappears the moment real content populates the page (IBM Carbon Design System, 2026). Usually a shimmer or a pulse runs across the shapes while you wait, signaling that the layout is still resolving.
What Is a Skeleton Screen?
Picture a rough sketch of the page, drawn live while the data is still on its way. That’s the whole idea.
Instead of a blank white screen or a spinner floating in the middle of nothing, you get gray boxes, bars, and circles parked roughly where text, images, and cards will eventually land.
The shapes borrow their logic from a wireframe. The difference is that a wireframe sits in a design file and this one runs inside the working interface.
It all falls under user interface design, the part of it concerned with giving people a sense of structure before the real thing arrives.
What gets previewed here is layout, never content. That’s why a skeleton never shows real text or real images, only placeholders shaped like them.
LinkedIn’s feed is the example most people have seen without thinking about it. Gray circles stand in for profile photos, gray bars stand in for headlines, and the arrangement matches the card layout the real posts will use once they load.
Who Created Skeleton Screens?
Product designer Luke Wroblewski coined the term in a 2013 blog post titled “Mobile Design Details: Avoid The Spinner.”
He was working on Polar at the time, a quick-tap polling app built around small micro-interactions. A generic spinner sitting between polls was the specific annoyance he wanted gone.
Polar is where the pattern first shipped, but Facebook is what made it common. Once skeleton screens landed in the News Feed redesign, other large platforms copied the approach and it stopped being a one-app trick.
Placeholder content itself is older than the name. Designers were blocking out gray boxes for unloaded data well before 2013. Wroblewski gave the habit a label and a rationale that stuck.
What Does a Skeleton Screen Look Like?
See the Pen
Modern E-commerce Mobile App Interface with a Skeleton Screen Loadingby Bogdan Sandu (@bogdansandu)
onCodePen.
The shape vocabulary is tiny.
- Rectangles and thin bars for lines of text
- Circles for avatars and profile photos
- Larger blocks standing in for images, thumbnails, and cards
Most of these get built with plain CSS boxes or with SVG. Sizing matters far more than color. A box that doesn’t match its eventual content causes the exact jarring jump the pattern exists to prevent.
From there you have a choice between a static skeleton that just sits there gray and still, and an animated one that adds motion to prove loading is actually happening.
Shimmer Animation
A shimmer is a soft gradient band that sweeps left to right across each gray shape on a loop.
It’s built with CSS keyframes, dragging a lighter gradient stripe across a darker base color every second or two.
Teams like it because the sweeping motion reads as “something is happening.” A spinner communicates the same thing, but it pulls attention to itself instead of leaving the layout underneath as the main event.
Pulse Animation
Pulse is the cheaper option. Each gray shape fades its opacity up and down on a loop. No gradient, no sweep, nothing to composite.
That matters on older phones and on pages stacking a long column of skeleton cards, where a shimmer on every one of them starts costing real frames.
Instagram and similar feed apps lean on the lighter approach for lower-end devices, giving up a bit of polish for smoother scrolling. Honestly, most people never notice the difference.
How Do Skeleton Screens Work?
IBM researchers Walter Doherty and Ahrvind Thadani found that systems responding within 400 milliseconds keep people engaged and productive, a finding known today as the Doherty Threshold (IBM Systems Journal, 1982).
Skeleton screens work the same lever. They don’t make a page load faster. They change how the wait feels to whoever is staring at the screen.
Jakob Nielsen’s research at Nielsen Norman Group breaks the bands down further. Under a tenth of a second feels instant. Under a second keeps a person’s train of thought intact. Past ten seconds, attention has already wandered off somewhere else.
A skeleton screen lives in that middle band. It hands the brain some structure to latch onto instead of a blank void, and the blank void is what most people actually find uncomfortable about waiting.
None of this speeds up a slow backend. The server takes exactly as long as it was always going to take. The skeleton just manages the gap in a way that respects the person’s attention.
Slack’s initial workspace load shows it well. Gray channel names and message bubbles appear almost immediately, well before the real conversation data streams in, and that early structure is what keeps the wait from feeling empty.
So this is a question of user experience. Perception, not raw speed, is the thing being adjusted.
Skeleton Screens vs Spinners vs Progress Bars
See the Pen
Responsive Mobile App Skeleton Screen with Loading Animationby Bogdan Sandu (@bogdansandu)
onCodePen.
All three patterns cover the same gap. Picking the wrong one for a given wait is a common mistake.
| Pattern | What it communicates | Best fit | Effect on perceived wait |
|---|---|---|---|
| Skeleton screen | Layout and structure | Feeds, cards, unpredictable fetch times | Lowers it noticeably |
| Spinner | Activity, nothing else | Short, generic waits | Little to no effect |
| Progress bar | A measurable endpoint | Uploads, downloads, known durations | Lowers it when accurate |
A loading spinner tells a person something is happening. That’s the entire message. No sense of how long, no hint of what’s coming.
Fine for half a second. It gets irritating once the wait stretches past a couple of seconds, because the spinner has no new information to offer no matter how long it keeps going.
A progress bar fixes part of that with a measurable endpoint, but only when the app genuinely knows how much is left. A bar that stalls at 90 percent erodes trust faster than showing no bar at all.
Skeleton screens split the difference. No promise about timing, but actual information about what the layout is going to look like.
In practice: progress bar when duration is knowable, spinner for something genuinely quick, skeleton for structured content with an unpredictable fetch, like a social feed or a product grid.
YouTube made that swap on parts of its homepage grid, dropping a generic buffering spinner for skeleton video thumbnails so the layout registers before a single frame loads.
What Are the Pros and Cons of Skeleton Screens?
Like any UI pattern, skeleton screens trade one set of problems for another. They aren’t a free upgrade.
What you get:
- Previews the final layout before any real data arrives
- Lowers perceived wait time without touching actual load time
- Smooths the transition into real content instead of a hard pop-in
- Cuts down layout shift, assuming the placeholder shapes match final content dimensions
What it costs, which teams tend to find out after shipping:
- Extra markup and CSS to build and then maintain
- Feels worse than no placeholder at all when the shapes don’t match the real content
- Can read as slower than a spinner if the skeleton lingers on screen too long
None of it touches server response time. Portent’s research on load time found conversion rates drop by 4.42% for every additional second a page takes to load, in the zero-to-five-second range it measured, and a skeleton screen does nothing to move that number.
What it buys is goodwill during the seconds the server genuinely needs. That matters for usability even when it doesn’t matter for the stopwatch.
Do Skeleton Screens Affect Core Web Vitals?
Yes, and the direction depends entirely on how closely the placeholder shapes match the real content’s dimensions.
Cumulative Layout Shift, one of Google’s three Core Web Vitals, measures that exact movement: how much visible content jumps around unexpectedly while a page finishes loading.
Size the skeleton to match and you prevent the jump. Size it carelessly and you cause it. Swapping a short gray bar for three lines of actual text shoves everything below it down the page.
- Good: CLS score of 0.1 or less, under Google’s current web.dev guidance
- Needs improvement: 0.1 to 0.25
- Poor: above 0.25
- Measurement window: scored at the 75th percentile of real user visits, not lab averages
Lighthouse audits treat correctly sized skeleton placeholders as stable content rather than a penalty, since the tool only flags shifts that happen after the skeleton is already in place.
News publisher Telegraph Media Group cut its 75th-percentile CLS score from 0.25 down to 0.1 and grew the share of page visits with a passing score from 57 to 72 percent, a case study documented on Google’s web.dev site.
Content loading above the fold carries the most weight in that scoring. A shift near the top of the viewport counts for far more than one buried at the bottom of a long feed.
Which Apps Use Skeleton Screens?
The pattern started in a small polling app. The platforms running it now are considerably larger.
| App | Where it shows up | Shape style |
|---|---|---|
| Airbnb | Listing search results | Card blocks matching photo and price layout |
| Medium | Article feed | Bars mimicking headline and byline |
| Twitter/X | Timeline | Circle avatar plus stacked text bars per post |
| Home grid | Variable-height blocks matching pin ratios |
Airbnb’s listing cards are a clean case of sizing done right. The placeholder block matches the photo’s aspect ratio almost exactly, so nothing jumps once the image resolves.
Pinterest goes a different way. It calculates the dominant color of each image and uses that as the placeholder tone instead of flat gray, so the grid system already looks colorful before a single photo has finished loading. It’s a nice touch, and it’s more work than most teams will sign up for.
The common thread across all of them is an asynchronous request, usually Ajax under the hood, with the skeleton filling the screen for however long that request runs.
When Should You Not Use Skeleton Screens?
Not every loading state wants one, and forcing them in everywhere backfires.
- One-off actions like a file upload or a payment confirmation need a measurable endpoint, not a layout preview. Progress bar territory.
- Content with no fixed structure can’t be guessed at, and a mismatched skeleton looks worse than showing nothing.
- Flashing a skeleton for a hundred milliseconds before swapping to real content creates more flicker than it prevents.
- Putting a shimmer on every single interaction trains people to associate the pattern with waiting, which defeats the point.
There’s also a real disagreement in the research about whether skeleton screens deliver on their core promise.
The Doherty Threshold and Nielsen’s response-time bands explain, in theory, why a structured placeholder should feel shorter than a blank wait.
A controlled study by Viget in 2017, with 136 participants split across a blank screen, a spinner, and a skeleton screen, found the opposite in practice.
- Blank screen: 2.29 seconds average perceived wait
- Loading spinner: 2.41 seconds average perceived wait, 74% agreed the content “loaded quickly”
- Skeleton screen: 2.82 seconds average perceived wait, only 59% agreed the content “loaded quickly”
Viget’s own reading of that result is worth repeating: a skeleton screen is novel enough to draw attention to itself, and attention paid to a wait makes the wait feel longer rather than shorter.
Skeleton screens still earn their keep on feeds and card grids where a layout preview does something useful. But treating them as an automatic perceived-performance win isn’t supported by the evidence.
How Do You Build a Skeleton Screen?
See the Pen
Responsive Skeleton Screen UI Patternby Bogdan Sandu (@bogdansandu)
onCodePen.
The order is fixed, and skipping a step is where most implementations fall apart.
- Map the final layout first: screenshot or sketch the real component exactly as it will render once data arrives.
- Extract the shapes: turn each text line, avatar, and image block into a rectangle, circle, or bar matching its real dimensions.
- Build the static markup: lay out those shapes in plain HTML and CSS, or as an SVG document, with no animation yet.
- Apply the animation: add a shimmer or pulse effect using CSS keyframes or a small JavaScript timer.
- Swap in real content: once the request resolves, replace the placeholder markup with the actual data in one clean transition.
Step two is the one that gets rushed. A placeholder shorter or taller than what eventually loads produces the layout shift the whole pattern exists to prevent, which is a slightly embarrassing way to fail.
Raw CSS and SVG are fine for a single component. Hand-coding turns tedious fast once a page carries a dozen card types.
A CSS loader generator speeds up the shape-and-animation stage for anyone who doesn’t want to hand-write keyframes for every variant.
All of this assumes the page already fetches its data through an API call. The skeleton is only the visual holding pattern while that request is in flight.
Which Skeleton Screen Library Should You Use?
Once a project has more than a couple of skeleton variants, most teams stop hand-building shapes and reach for a library.
| Library | Framework | Animation | Best fit |
|---|---|---|---|
| react-content-loader | React, React Native | SVG shimmer | Custom shapes, small bundle |
| react-loading-skeleton | React | CSS shimmer | Quick drop-in placeholders |
| Ant Design Skeleton | React (Ant Design) | CSS pulse | Teams already on Ant Design |
| Material UI Skeleton | React (MUI) | CSS pulse or wave | Teams already on MUI |
| Chakra UI Skeleton | React (Chakra) | CSS fade | Teams already on Chakra |
react-content-loader is the lightest of the group. Pure SVG, under 2 kilobytes with zero dependencies thanks to tight SVG optimization, and close to 958,000 weekly downloads on npm per the package’s own registry listing.
react-loading-skeleton goes with plain CSS boxes instead of SVG paths. Easier to restyle on the fly, slightly heavier to render at scale.
Ant Design, Material UI, and Chakra UI each ship a Skeleton component inside their own component library, so anyone already on one of those systems gets a matching placeholder without adding a package.
Outside React, native mobile has its own answers. Shimmer for Android, SkeletonView for iOS, both built against their platform’s rendering pipeline instead of a shared web-style component.
For a single page with one or two variants, a new dependency rarely pays for itself. Hand-written boxes and one keyframe animation cover that case at zero added weight, and personally I’d stay there longer than most people do.
How Do You Make Skeleton Screens Accessible?
A shimmering placeholder that looks fine to you can genuinely bother someone with motion sensitivity.
So wrap the shimmer or pulse in a media query that checks for prefers-reduced-motion, and fall back to a static gray shape with no movement when the setting is on.
The population this protects is not small. As many as 35% of US adults aged 40 and older have experienced some form of vestibular dysfunction, according to the National Institute on Deafness and Other Communication Disorders.
Screen readers need a separate signal, since a moving gray box means nothing to someone who can’t see it.
Most guidance points to an ARIA live region or a busy state so assistive tech announces that content is loading. GitLab’s Pajamas design system takes the opposite position for its own skeleton component, arguing a live region is unnecessary when the placeholder only stays up for a few seconds.
Both camps agree on one point. The shapes carry no meaning by themselves, so mark them decorative and keep them out of the accessibility tree rather than letting a screen reader read out a row of unlabeled gray rectangles.
FAQ on What Are Skeleton Screens
Is a Skeleton Screen the Same as a Wireframe?
No. A wireframe is a static design file used before development starts.
A skeleton screen is a live loading state built into the working interface, rendering while real data is still on its way, not sitting in a design tool.
Do Skeleton Screens Actually Improve Conversion Rates?
Not directly. No published study isolates skeleton screens as the sole driver of conversion lift.
Their documented effect sits in perceived wait time and layout stability, both of which correlate with conversion in broader load-time research.
What Mistakes Do People Make Building Skeleton Screens?
Most often, leaving skeleton shapes visible after the real data has already come back, because the swap logic was never wired to the response event.
A close second is rendering a fixed skeleton count that doesn’t match how many items actually load.
How Long Should a Skeleton Screen Display Before Showing Real Content?
There’s no fixed number. The skeleton stays only as long as the fetch takes and disappears the instant data arrives.
As a design ceiling, most guidance keeps it well under the ten-second mark where attention drops off entirely, per Nielsen’s response-time research.
Can Skeleton Screens Be Used in Native iOS or Android Apps?
Yes. Native implementations skip CSS and animate shimmer effects through the platform’s own graphics layer, Core Animation on iOS and hardware-accelerated rendering on Android.
That keeps motion smooth on older devices, which is why most apps build a native version instead of sharing a web component.
Where Should You Start With What Are Skeleton Screens?
Start with an audit. Work out which page sections carry a genuine, unpredictable network delay before writing a single shape or animation.
Then pilot on your highest-traffic feed, watch the layout shift score after launch, and only expand to the remaining pages once that number holds steady. The middle step is the one people skip, and skipping it is how a good pattern turns into a liability.
Put the Cumulative Layout Shift threshold of 0.1 next to Viget’s finding that skeleton screens don’t reliably cut perceived wait, and the case gets sharper: the pattern earns its place through layout stability, not speed. That stability costs extra markup and CSS weight. A fast, well-cached page has no particular reason to pay it.
From here, browsing ready-made CSS loaders covers the loading states a skeleton can’t, button spinners being the obvious one.
Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.
- What is Backend in Web Development? - September 13, 2026
- What is Frontend Development? - September 11, 2026
- How to Make a Button in Figma: Design Best Practices - September 10, 2026
