Many apps show a grey skeleton layout — outlined boxes and bars in the shape of the coming content — while data loads, instead of a spinner or a blank area. What does that actually improve, and what does it not?
answer
- perceived time, not measured time
- structure beats a spinner
- reserve the space it will need
- short waits make it a flicker
basics
~20 sA skeleton improves perceived speed: it shows the page's structure immediately, so the wait feels shorter and more predictable. It does not make data arrive any sooner, and a skeleton whose size differs from the real content causes the page to jump.
solid answer
~50 sA skeleton is a perception tool, not a performance fix. Showing the layout — header, card outlines, text bars — tells the user the page is working and roughly what is coming, so the same wait feels shorter than staring at a blank area or a spinner that conveys no structure. It also gives the browser something real to paint, which is why a skeleton usually improves first paint even though the data is unchanged. The limits matter just as much. The request still takes exactly as long. If the skeleton's boxes are not close to the real content's size, the swap shifts the layout and the page feels cheap. And a skeleton on a region that resolves in 100 ms is worse than nothing: the flash of placeholder reads as a glitch. Reserve skeletons for waits long enough to notice, and size them like the content they stand in for.
go deeper
Say plainly that a skeleton shows the shape of the page while data loads, which makes the wait feel shorter, and that it must be roughly the size of the real content so nothing jumps.
Separate perceived from measured: explain that first paint improves while the data timing does not, and describe the delay-and-minimum-duration trick that stops the placeholder flickering on fast responses.
Demonstrate that you treat the skeleton as space reservation and state management — sized from the real layout, marked busy for assistive tech, and with a defined failure path — not as decoration bolted on at the end.
Own the boundary: decide where perception work is a legitimate fix and where it is masking a slow dependency that should be cached or precomputed, and make sure the team is not reporting perception changes as throughput wins.
## Perceived time versus measured time Two pages can take exactly 1.5 seconds to become useful and feel completely different. One shows a white screen for 1.5 seconds then everything at once; the other shows a laid-out page with placeholder bars at 300 ms and fills them at 1.5 seconds. Nothing about the data changed — the second page simply gave the user information earlier: *the site is working, this is what the page will look like, content goes here.* This is why performance work distinguishes measured time (what a stopwatch or a metric records) from perceived time (how long the wait felt). Uncertainty inflates perceived time. A wait with visible progress and a predictable shape feels shorter than an identical wait with no feedback at all. ## What a skeleton is A skeleton screen is placeholder UI that mirrors the structure of the content it is standing in for: a grey block where the avatar goes, three bars where the title and two lines of text go, a rectangle the size of the chart. It is usually plain markup and CSS, so it can be part of the first streamed chunk of HTML and needs no data at all. Compared to the alternatives: - **Blank area** — zero information. The user cannot tell loading from broken. - **Spinner** — says "something is happening" but nothing about what or where. A centred spinner also throws away the page's layout, so the real content's arrival is a full re-layout. - **Skeleton** — says what is coming and where, and the page's shape is already correct when the real content lands. ## Why it often improves a real metric too A skeleton gives the browser paintable content early, so first paint typically happens sooner. But be careful about which metric you claim. Placeholder boxes are not meaningful content: the largest contentful element is generally still the real image or block of text that arrives later, so the largest contentful paint is not fixed by adding a skeleton. If an interviewer hears "we added skeletons and our loading metrics all improved," the honest version is that first paint improved and the experience improved, while the time until the content is actually there did not. ## The two ways skeletons backfire **Wrong size.** The skeleton reserves 80px, the real card is 220px, and everything below jumps when the swap happens. That layout shift is measurable, annoying, and can cause mis-taps if it lands under the user's finger. A skeleton's job is partly to *reserve space*, so its dimensions should be derived from the real component's layout rather than drawn by eye. Where the real height varies, pick a representative size and clamp the content rather than letting the container grow unpredictably. **Wrong duration.** If the data arrives in 80 ms, the skeleton appears and disappears as a flicker, which reads as a rendering bug. Two common mitigations: do not show the placeholder at all until the wait crosses a threshold of a couple of hundred milliseconds, and once it is shown, keep it up for a minimum period so it cannot flash. For genuinely fast regions, showing nothing and letting the content appear is the better experience. ```css .skeleton { min-height: 220px; background: #eee; } @media (prefers-reduced-motion: reduce) { .skeleton { animation: none; } } ``` ## Details that separate a good implementation - **Reserve, do not just decorate.** The skeleton should hold the space, not merely look like the content. - **Respect motion preferences.** Shimmer animations should be disabled under `prefers-reduced-motion: reduce`. - **Announce state, not fake content.** Mark the container `aria-busy="true"` while it is a placeholder and remove that when real content lands, so a screen-reader user is not read a wall of empty boxes. - **Have a failure state.** If the request fails, the skeleton must become an error message. A skeleton that shimmers forever is the worst outcome of all, because the user cannot tell it from a slow success. ## The honest summary Skeletons buy attention, not time. They are worth adding when the wait is real and the structure is predictable, and they are worth skipping when the wait is short or the layout is unknowable. They never substitute for making the underlying request faster — if the interviewer's follow-up is "and what did you do about the 900 ms API call?", "we added a skeleton" is not an answer.
- How do you avoid a skeleton flashing on and off for a fast response?Delay showing it. Only render the placeholder once the wait exceeds a threshold of roughly 200 ms, and once shown, keep it visible for a short minimum so it cannot blink out instantly. For regions that reliably resolve in under that threshold, show nothing — an unannounced fast update feels better than a flicker.
- Does adding a skeleton improve the largest contentful paint?Usually not. Placeholder boxes are not meaningful content, so the largest contentful element is still the real image or text block that arrives later. What a skeleton reliably improves is first paint and the felt experience; claiming it fixes the largest contentful paint is a claim the field data will contradict.
- What should happen to a skeleton when the request behind it fails?It has to become an error state with a retry affordance. A skeleton that keeps shimmering is indistinguishable from a slow success, so the user waits indefinitely. This matters most in streamed pages, where the response status is already committed and the failure can only be expressed inside the region itself.
A skeleton is the outline a restaurant sets on your table — cutlery, napkin, glass. The food takes just as long, but you can see a meal is coming and where it will land.
saying these in an interview costs you the question
- Says a skeleton makes the data load faster
- Sizes the placeholder by eye, so the swap shifts the layout
- Shows a skeleton for a request that finishes in 50 ms
- Leaves the skeleton shimmering forever when a request fails
- Claims skeletons improve the largest contentful paint