When should you use a loading spinner?

When the wait is short, the duration is genuinely unknown, and you cannot show the shape of what is coming. For anything where the layout is predictable, a skeleton communicates more. For anything long enough that somebody might leave, a spinner is the wrong instrument because it says only that something is happening.

How long can a spinner be shown before it becomes a problem?

Jakob Nielsen's response-time limits still apply: under 0.1 seconds feels instantaneous and needs nothing, up to 1 second keeps a train of thought intact, and 10 seconds is the outer edge of held attention. A spinner past roughly ten seconds needs replacing with real progress, an estimate, or permission to leave and be notified.

Should you show a spinner for very fast operations?

No. A spinner that appears and vanishes within a couple of hundred milliseconds reads as a flicker and makes the interface feel unstable. Delay showing it by around 200 to 300 milliseconds, so fast responses never trigger one at all.

What is the difference between a spinner and a progress bar?

A spinner is indeterminate: it says work is happening and nothing about how much remains. A progress bar is determinate and requires you to know the total. Use a bar wherever the amount is knowable, because a number a person can watch move is far easier to wait through than an animation that never changes.

Is a spinner accessible?

Not on its own. Movement without text tells a screen-reader user nothing, so the loading state needs an announcement through a live region or an accessible label. The animation must also respect the reduce-motion preference, which means a non-spinning indicator rather than nothing at all.

Loading Spinner

An indeterminate progress indicator shown while a system is working and cannot say how long it will take.

UI Components

A loading spinner is an indeterminate progress indicator: it says the system is working and cannot say how much longer. That limitation defines where it belongs and where it does not.

It is the default for any wait, which is why it appears in places it should not. A spinner is the right answer only when the duration is genuinely unknown, the wait is short, and there is nothing more informative to show.

The timing thresholds

Perceived speed is governed by numbers that have not moved in decades. Jakob Nielsen's response time limits, published in 1993 from research by Miller in 1968 and Card and colleagues in 1991:

Duration	What the person experiences	What to show
Under 0.1s	Instantaneous	Nothing. The result is the feedback
0.1–1s	A noticeable pause, thought unbroken	An immediate press state, no spinner
1–10s	Waiting, attention held	A spinner, or better, a skeleton
Over 10s	Attention gone	Real progress, an estimate, or a way to leave

Two practical consequences. Below one second a spinner adds visual noise to something that felt fine. Above ten it stops being adequate, because an animation that never changes gives somebody no way to judge whether to keep waiting.

The flicker problem, and its fix

A spinner shown the instant a request starts will appear and vanish for every fast response, which reads as instability rather than speed.

The fix is a delay before showing it, usually 200 to 300 milliseconds. Responses faster than that never produce a spinner. Slower ones get it, and by then the person is expecting something.

The companion rule: once shown, keep it visible for a minimum period, perhaps 400 milliseconds. A spinner that flashes for 50 milliseconds because the response arrived just after the threshold is the same flicker from the other direction.

When something else is better

A skeleton wherever the shape of the result is known. It preserves the layout, prevents the jump when content arrives, and tells the person what is coming.

A progress bar wherever the total is knowable. Uploads, imports, multi-step jobs. A number moving is far easier to wait through.

An optimistic update wherever the result is predictable and reversible. Showing the outcome immediately and rolling back on failure removes the wait entirely, at the cost of designing the rollback. See interaction design.

Nothing at all for anything under a tenth of a second.

A background job with a notification for anything long. Blocking somebody on a two-minute export is a design decision, and usually the wrong one.

Spinners in B2B interfaces

Per-row spinners multiply. A table where each row can load independently produces a screen of spinning elements. Loading the region rather than each row is usually calmer and no slower.

Full-page spinners hide what is already known. Most enterprise screens can render their navigation, their heading and their empty structure immediately, with only the data pending. Replacing the whole page with a spinner discards information the product already has.

Long operations are normal. Reports, exports, syncs and bulk updates routinely exceed ten seconds. These need progress and the ability to leave, not an indicator that spins for two minutes.

Never spin without a timeout. A request that fails silently leaves an interface spinning forever, and the person concludes the product is broken rather than that something errored.

Where the spinner is a symptom

A spinner is often a design answer to an engineering problem, and it is worth asking which one you have.

A wait that could be removed. Data fetched on click that could have been prefetched on hover or on page load. The fastest loading state is the one that never appears.

A wait that could be split. A screen that loads everything before rendering anything, when most of it was already available. Rendering in parts turns one long wait into several short ones, most of which nobody notices.

A wait that could be moved. Work done while somebody watches that could have been done in the background, with a notification afterwards.

Reaching for a better indicator is the right move when the wait is genuine. When the wait is avoidable, a nicer spinner is a way of getting comfortable with it.

In practice

A dashboard replaces its entire content area with a centred spinner while data loads.

The load takes about three seconds against real customer data. In that time the person sees nothing: not the layout, not the headings, not which widgets exist. When the data arrives the whole screen assembles at once and the layout shifts as content sizes itself.

Replacing the spinner with skeletons of the actual widgets changes the experience without changing the speed. The structure is visible immediately, so somebody can start reading the headings and deciding where to look, and nothing jumps when the numbers arrive.

The measured load time is identical. What changed is that the three seconds are now spent orienting instead of waiting.

Where teams get it wrong

Spinning for fast responses. A flicker that reads as instability.
A spinner where a skeleton fits. Discarding a known layout for an animation.
Indeterminate when the total is known. A progress bar was available.
Full-page spinners. Hiding structure the product could already render.
No timeout. An interface that spins forever after a silent failure.
Motion with no announcement. Nothing at all for a screen-reader user.

Learn more

UI/UX design for B2B SaaS →Dashboard design: patterns and examples →