A Skeleton Screen Is a Promise About Shape

I opened the newsroom hub on a throttled connection to watch something that isn't supposed to be noticed: the wait. Before a single headline landed, the page already had rails, card shapes, and a rectangle where a badge would sit. Nothing was blank. Nothing spun. The layout had arrived first, without its words.

That grey, breathing outline is a skeleton screen: a static placeholder that mimics the block shape of incoming content, not a blank page and not a spinner. In Next.js, `loading.tsx` is the file that renders while a route's real content is still loading. It wraps the route in a waiting state and swaps out when content is ready. Most teams treat what goes inside as an afterthought.

I don't, because a skeleton makes a claim before it has earned the right to. It is a structural promise about shape, not decoration. In advance and in pixels, it tells the visitor where the title will sit and how wide the image will be. It also signals how many lines of text to expect. Break that promise and the visitor pays the same tax they pay for a lying Loading string. That is a small loss of trust, spent the moment real content resolves into a shape nobody warned them about. Call that shape drift: a skeleton that stops matching the layout it stands in for. The promise turns into a small lie on every load.

Download

The Blank Page Trained Us to Expect Nothing

Before skeleton screens, software waited in one of two costumes: blank white space, or a spinner going nowhere. Both are honest in the dullest way possible. Nothing about them can be wrong when the real content lands, because they promised nothing. That is also the failure. They train the visitor to expect nothing from the interface at exactly the moment the interface has the most to say about what is coming.

The tempting middle ground is the one component libraries ship by default: an identical grid of grey rectangles. It gets dropped onto every route because a review wants a loading state before launch. Nobody studied what that particular route actually looks like. It costs nothing to add and promises nothing true, which makes it barely better than the blank screen it replaced. A skeleton only becomes an improvement once it stops being generic and starts looking like the destination. A wait that promises nothing fails safely. A wait that promises the wrong shape fails loudly, one beat later, exactly when the real page tries to prove the pause was worth it.

The Shape Is the Promise, Not the Word

I made a version of this argument about words in Waiting Is a Design Surface. A wait that says Loading when the system knows exactly what it is doing is quietly apologising for existing. A wait that says something true admits the work is real. The same test holds for shape. A visitor reading an interface during a wait is looking for a signal about what is coming. That signal can arrive as a word or a rectangle. A lying signal in pixels breaks trust just as fast as a lying signal in prose. It just does it more quietly. Nobody screenshots a slightly wrong-shaped skeleton to complain. They flinch once, when the real page lands somewhere else, and move on before they can name what bothered them.

Ask, the assistant on this site, keeps its own wait state in words. A small rotating verb turns over while an answer streams in, with nothing to look at but a sentence taking shape. The newsroom, the articles, and the tools on this site keep theirs in shape instead. Rails, frames, and lines stand in for content that has not arrived yet. Same decision, different material. Either way, the wait is a place I designed on purpose, not a gap I filled in on the way to launch.

Nineteen Skeletons and a Preview Route Nobody Sees

Every skeleton on this site starts from one shared primitive: a grey, rounded rectangle that pulses gently while it waits. It is marked in the code so screen readers and browser tooling both know what they are looking at. From that primitive, nineteen separate skeleton components exist in the codebase, each hand-shaped to its route. They are wired through twenty-nine `loading.tsx` files across the site. The newsroom hub's skeleton carries the same rails and card proportions as the cards that will replace it. Two more shapes from that same primitive sit below, live rather than a screenshot: Ask and the newsroom hub, each on desktop or mobile.

Nineteen hand-built files are real maintenance. They are checked at a QA route called `skeleton-preview` so a mismatch can be caught by looking at a screen, not by throttling a network and hoping. None of this argues for skeletonising every wait. A button that resolves in two hundred milliseconds is better served by a spinner or an optimistic update. A full-page skeleton would vanish before anyone had time to read it.

The Stair That Isn't There

There is a name for the jolt when a foot expects a step of one height and lands on a step built to another. It is the missing-stair reflex: a small stumble your body produces even though nothing is broken. Your legs notice the wrongness a half-second before your brain catches up. Scrolling a page mid-load does the same thing to the eye and the hand. By the second glance, you have already built a rough map of where the title sits and how wide the image will be. That map even predicts how many lines the paragraph takes. It is based entirely on the skeleton in front of you.

When the real content resolves into a different shape, there is a smaller version of that same stumble. Nothing has broken. The page still works. You still flinch, because the promise the shape made a second earlier did not hold, and your eyes had already started trusting it.

Isn't This Just Placebo?

Give the objection its full weight. Luke Wroblewski named the pattern in 2013 while shipping Polar: a spinner makes people watch the clock, while a blank version of the page into which content gradually loads focuses them on progress instead. Avoid The Spinner Nielsen Norman Group later summarised the same bet. A wireframe-like wait creates the illusion of a shorter load and lowers cognitive load by previewing structure before the words arrive. Skeleton Screens 101 If the benefit is mostly perception, the argument goes, skeleton screens are perceived-performance theatre: a psychological trick that makes a wait feel shorter without making the wait itself one second shorter. The network call underneath takes exactly as long whether the visitor is staring at a grey box or a blank one. By that logic, calling the shape a promise is generous branding for what is really a distraction. It is the visual equivalent of hold music that makes a queue feel shorter while doing nothing to make it move faster.

That critique is fair against decoration. Tim Kadlec's later reading of the pattern is sharper still: when the skeleton falsely represents what is coming or where it will sit, the confusion overcomes any perceived-speed benefit. Effective Skeleton Screens Aim that warning at any skeleton drawn from imagination rather than from the component it stands in for. It stops working against a skeleton built from the real layout's own code. The newsroom skeleton is not a mockup of the newsroom. It is the newsroom's own card shapes, rendered before their contents exist. The same loading container announces `aria-busy` to assistive technology while its decorative bones stay hidden from screen readers. Reduced motion can strip the shimmer and leave the shape at a duller opacity without losing anything true. Theatre would keep the shimmer and drop the accuracy the moment nobody was watching closely. A kept promise can lose the shimmer entirely and still tell the truth about what is coming. The truth was never the animation. It was the shape.

A skeleton screen only ever proves one thing: whether the shape it showed you matches the shape you got. Every skeleton on this site earns that promise the same way, checked against its real component instead of drawn once and left to drift. I still open the skeleton preview before every redesign, because somewhere a visitor trusted the shape before the page had earned it.