Loading Spinner
An indeterminate progress indicator shown while a system is working and cannot say how long it will take.
UI ComponentsA spinner says “working” and nothing else. That is appropriate when the duration is genuinely unknown and the wait is short — under about a second, where anything more elaborate would flash and vanish. It is the wrong choice in two directions: when you do know the total (use a progress bar) and when the wait is long enough that the user needs to see the shape of what is coming (use skeleton loading).
Timing rules prevent most spinner complaints. Delay it by 200–300ms so fast responses never flash. Once shown, keep it for a minimum period so it does not strobe. Replace full-page spinners with in-place ones wherever only a region is refreshing, and do not reset the scroll position when the content arrives.
In practice
A dashboard showed a full-page spinner on every filter change, including ones that resolved in 80ms. The page flashed white on almost every interaction and read as slow. Adding a 250ms delay and confining the indicator to the chart region changed nothing about the response times and stopped the “it's sluggish” feedback.
Where teams get it wrong
- Spinners with no delay, flashing on responses that were already fast.
- Full-page spinners for a partial update.
- Spinners for long operations where a real progress bar was possible.
- No timeout or failure path — a spinner that runs forever is an unreported error.
- Losing scroll position when the content replaces the spinner.
Learn more
You may ask
Frequently Asked Questions
When should you use a spinner instead of a skeleton?
For short, indeterminate waits and for actions rather than content — saving, submitting, refreshing a value. Use a skeleton when a known layout of content is arriving and the wait is long enough to see.
How long before a spinner should appear?
Around 200–300ms. Showing it immediately makes fast responses flash, which reads as instability rather than speed.
Related terms
All terms- Skeleton LoadingPlaceholder shapes matching the layout of content that is still loading, shown instead of a spinner so the page keeps its structure.
- Progress BarA determinate indicator showing how much of a known task is done — usable only when the total is actually known.
- Empty StateWhat a screen shows when it has no content yet — the first screen every new account sees, and usually the last one anybody designs.
- Error StateWhat an interface shows when something failed — which system failed, whether the user's work survived, and what they can do next.
Defined by Mara Last reviewed .
Let's talk about your product.
Happy to look at what you're building and say where design would move the needle.
Contact Us