20 CSS Loaders

Three different patterns, three different UX moments. (1) Nothing at all — for operations under ~200ms. Showing a loader briefly is more jarring than no loader at all because the user perceives the screen flash as a glitch. Skip loaders for fast operations. (2) A spinner / loader (Demos 01, 02, 05, 08, 11, 19) — for operations that take 200ms-3s where you DON'T know the eventual result shape. Generic indeterminate spinners say "we're working on it, but we don't have layout info yet." Use for: API calls that return JSON, search-as-you-type, OAuth handshakes, form submissions, payment processing. (3) A skeleton screen (Demo 03) — for operations 500ms+ where you DO know the eventual content shape. Skeletons preview the layout — a gray rectangle where the article image will land, gray lines where the headline will land, gray blocks where the body paragraphs will land. Nielsen Norman Group research shows skeleton screens reduce perceived wait time by ~22% vs spinners because the user's brain starts processing the layout before the data arrives. Facebook, LinkedIn, YouTube, Medium, Slack, Notion all use skeletons for their main feed/document loading. (4) A progress bar (Demo 04, 09) — for operations 3s+ where you KNOW the % complete. File uploads, video processing, multi-step workflows. Bar gives the user a sense of "how much longer." Don't fake the percentage if you don't actually know it — that's a UX dark pattern. Use an indeterminate progress (Demo 04 shimmer) instead. The 20 demos in this collection cover all four cases.

Depends on your stack and bundle budget. If you're on React + react-spinners: it ships ~30 spinners as ~8kb gzipped. Excellent if you're ALREADY using it. If you're adding it just to get one loader, that's 8kb for one component. If you're on React + react-loading-skeleton: it's specifically for skeleton screens, ~4kb gzipped, exposes a <Skeleton width height count /> API. Great DX, but adds a React dependency you may not need. If you're NOT on React (Astro, Vue, Svelte, Rails ERB, vanilla, WordPress): all the React-specific options force you to bring React into your bundle. SpinKit / loaders.css / epic-spinners: framework-neutral CSS-only loader libraries (~2-5kb gzipped). These are essentially what this collection IS — except this collection is MIT-licensed copy-paste with 20 hand-picked patterns instead of 30-100 mediocre ones. loading.io: web tool to generate loaders, often paywalls the source code or watermarks SVGs unless you pay. This collection's 20 loaders: 0 bytes of JavaScript, ~1-3kb of CSS per demo (only the ones you use), zero framework lock-in, MIT-licensed, modify-and-resell allowed. Best fit for: marketing sites, Astro/Eleventy static sites, Rails or Django ERB templates, WordPress themes, any non-React project, and React projects where you want to avoid framework-coupled loading state libraries.

Demo 03 (CSS Skeleton Screen Loader) ships the canonical content-placeholder pattern. The mechanic: (1) Build a skeleton DOM that mirrors your eventual content's layout — gray rectangle where the image goes, gray lines where the headline goes, gray blocks where the paragraphs go. Use background-color: rgba(0,0,0,0.06) on light themes or rgba(255,255,255,0.06) on dark themes. (2) Add the shimmer effect via a linear-gradient sweep: background: linear-gradient(90deg, var(--skeleton-bg) 0%, var(--skeleton-shimmer) 50%, var(--skeleton-bg) 100%); background-size: 200% 100%; animation: shimmer 1.5s ease-in-out infinite; where the keyframe shifts background-position from 200% 0 to -200% 0. (3) Swap the skeleton for real content by setting display: none on the skeleton element + display: block on the real content when your data arrives. Three production-grade details most online tutorials skip: (a) Match dimensions exactly. If your real headline is 28px tall, the skeleton line must be 28px tall — not 16px. If the dimensions drift, the user sees layout shift when real content swaps in (terrible CLS score, Core Web Vital penalty). (b) Don't animate skeleton lines individually. 20 separate animation declarations = 20 animation frames per second × N elements. Put ONE animation on a single pseudo-element that overlays the whole skeleton card — or use a single shared keyframe via animation-delay: var(--i). (c) Respect prefers-reduced-motion. Some vestibular-sensitive users can't tolerate the shimmer sweep — fall back to a static gray rectangle. All 20 demos in this collection respect this.

Demo 09 (CSS Circular Progress Loader) ships the pure-CSS implementation. The technique uses conic-gradient (modern browsers, no SVG needed) or SVG stroke-dasharray (universal support, more code). Conic-gradient version (recommended for modern apps): background: conic-gradient(var(--primary) calc(var(--progress) * 1%), var(--track) 0) where --progress is a CSS custom property updated via JS (or pure CSS @property animation for indeterminate). Add a circular mask via ::before { background: var(--bg); border-radius: 50%; inset: 6px; } to create the ring shape. Inside, position a <span> with position: absolute; inset: 0; display: grid; place-items: center; showing the percentage. SVG version: two stacked <circle> elements, the second with stroke-dasharray="circumference" and stroke-dashoffset animated from circumference to 0. Add transform-origin: center + transform: rotate(-90deg) so the stroke starts from 12 o'clock instead of 3 o'clock. Cost comparison: react-circular-progressbar ~5kb minified + requires React. This demo: ~25 lines of CSS, zero JS, no library. Browser support for conic-gradient: Chrome 69+, Safari 12.1+, Firefox 83+ — universally supported. The CSS transition: --progress 0.6s ease-out (with @property) animates smoothly between step changes — but it's an INP-safe transition (just paint, no layout).

Demo 16 (CSS Typing Dots Loader) ships the messaging app pattern. Three dots that bounce sequentially to indicate "the other person is typing." The pattern: (1) Three small circles (8-10px) arranged in a row inside a chat-bubble shape. (2) Each dot has the same animation but staggered: .dot:nth-child(1) { animation-delay: 0s } .dot:nth-child(2) { animation-delay: 0.2s } .dot:nth-child(3) { animation-delay: 0.4s }. (3) The animation: a 1.4s loop that translates the dot upward by ~6px at the 30%-40% keyframe, then back. animation: typing-bounce 1.4s ease-in-out infinite;. Three production-grade details: (a) Use a chat-bubble container around the dots — a rounded rectangle with the message-tail SVG/CSS — so it matches the rest of your chat UI. (b) Animate transform: translateY(-6px) not top: -6px — translate is GPU-accelerated. (c) Add a fade-in/out wrapper for when the typing state toggles — the dots shouldn't pop into existence. opacity: 0; transition: opacity 0.2s then opacity: 1 when the typing flag flips. Production usage: Discord, WhatsApp, iMessage, Slack, Telegram, Microsoft Teams all use variants of this pattern. The pattern is part of the conversational UI lexicon — users immediately recognize it as "the other side is composing."

Five accessibility considerations matter for loaders, and all 20 demos in this collection address them. (1) role="status" on the loader's outer wrapper. Tells assistive tech that the element conveys status information. Screen readers (NVDA, JAWS, VoiceOver, TalkBack) announce the content politely without interrupting the user's current task. (2) aria-live="polite" in addition to role="status" (technically the role implies it, but explicit doubles up nicely for buggy older assistive tech). Polite = announce when the user is idle. Avoid aria-live="assertive" for loaders — assertive interrupts the user, which is jarring for routine "loading" announcements. (3) Visually-hidden text inside the loader: <span class="sr-only">Loading…</span> with .sr-only { position:absolute; width:1px; height:1px; padding:0; margin:-1px; overflow:hidden; clip:rect(0,0,0,0); white-space:nowrap; border:0; }. The spinning ring (Demo 01) means nothing to a blind user — the visually-hidden "Loading…" text IS the announcement. (4) Update the text when state changes. When loading completes, swap the inner text to "Loaded" or remove the loader from the DOM entirely. aria-live will announce the change. (5) prefers-reduced-motion: reduce — for vestibular-sensitive users (people who experience motion sickness from continuous motion), pause or simplify the animation. Don't just remove it (then no loading indication at all) — replace with a static "Loading…" text or a single-frame icon. Common mistake most online tutorials make: animating only with CSS without any aria/role markup. Blind users have no idea your app is loading. The 20 demos here ship the markup correctly out of the box.

Determinate loaders (Demos 04, 09, 10, 17) show a measurable percentage of completion: progress bar at 47%, circular ring at 73%, liquid fill at 28%, staircase at step 3 of 5. Use determinate when you KNOW the eventual % — file uploads (you know the file size, you know bytes uploaded), video transcoding (frame count), multi-step forms (current step vs total), bulk operations (records processed). Determinate gives the user a sense of "how much longer" — a powerful psychological win for operations taking 5s+. Indeterminate loaders (Demos 01, 02, 05, 08, 11, 12, 13, 18, 19) show that work is happening but don't show how much remains. Use indeterminate when you DON'T know % — API calls returning JSON (you don't know what the server will return until it does), database queries, search-as-you-type, OAuth handshakes, ML inference. Don't fake a percentage just to feel like you have a determinate loader — that's a UX dark pattern. Users notice fake progress bars ("why did it stick at 97% for 10 seconds and then jump to 100?") and lose trust. Hybrid (Demo 03 skeleton): technically indeterminate but feels determinate because the skeleton previews the layout. The user perceives "about as long as it takes to render this card" even though we have no estimate. Best of both worlds — most modern apps use skeletons for indeterminate operations where they DO know the eventual layout.

Not if you follow the same rule as all CSS animations: animate transform and opacity only. Every loader in this collection follows this — spinning ring uses transform: rotate(360deg), not border-rotation; bouncing balls use transform: translateY(), not top; skeleton shimmer uses background-position (paint-only, not layout). All transforms and opacity changes are GPU-accelerated on the compositor thread — they DON'T trigger layout recalculation, so they DON'T affect INP (Interaction to Next Paint), the Core Web Vital that replaced FID in March 2024. Five loader-specific gotchas: (a) Don't animate border-radius on a continuous loop — repaints the entire element every frame. (b) Don't animate box-shadow on a continuous loop — same problem, plus shadows are GPU-expensive on mobile. (c) Don't use backdrop-filter on a loader that overlays a long scrollable page — backdrop-filter re-evaluates on every scroll frame, tanking scroll FPS. (d) Avoid SVG stroke-dashoffset animation for high-frequency loops — it's repaint-heavy. Use conic-gradient instead (Demo 19). (e) Limit concurrent loaders — three skeleton cards animating simultaneously is fine, but 50 stacked into a virtual-scroll list will saturate the compositor on low-end Android. Use animation-play-state: paused on off-screen skeletons via IntersectionObserver. All 20 demos in this collection: 95+ Performance score on Pixel 5 baseline. Skeleton screens actually IMPROVE perceived performance (lower CLS, lower TTI feel) compared to spinners — Nielsen Norman Group ~22% reduction in perceived wait time.

Common mistake: showing a loader for every async operation, even if the operation finishes in 80ms. The user sees a brief loader-flash that's more jarring than seeing nothing — their brain interprets the flash as a glitch. Fix: minimum-loader-time pattern. Two strategies: (1) Delay before showing. Wait ~200ms before showing the loader. If the operation finishes before then, never show it. const t = setTimeout(() => setLoading(true), 200); fetch(...).finally(() => { clearTimeout(t); setLoading(false); }). Operations under 200ms = no loader shown. Operations over 200ms = loader appears after 200ms and stays until done. (2) Minimum visible duration. Once shown, the loader stays visible for at least 500ms even if the operation finishes sooner. Prevents flash from "loader appears at 195ms, disappears at 220ms" (25ms flash, terrible). Combine both for best UX: 200ms grace period + 500ms minimum visible duration. Three patterns for the loader fade: (a) Instant on, fade out — when the operation finishes, fade the loader's opacity 1→0 over 200ms then remove. Feels polished. (b) Fade in + fade out — fade in over 100ms when shown, fade out when removed. Smoothest. (c) Replace with content immediately — when content's ready, swap loader for content with no fade. Snappiest, best for skeleton screens (the skeleton IS the layout placeholder, replacing it with real content feels natural). React: useDebounce(loading, 200). Vue: <Transition appear>. Astro: CSS transitions on a class toggle. None of this is loader-design-specific — it's wrapping logic that applies to all 20 demos.

Quick decision guide for all 20 demos. Generic API call / form submit (200ms-3s): Demo 01 (Spinning Ring) — the canonical pattern, universally recognized, works in every context. Content placeholder while loading a feed/article/document: Demo 03 (Skeleton Screen) — the Facebook/LinkedIn/YouTube pattern. File upload / video processing / bulk operation with known progress: Demo 04 (Progress Bar) for linear, Demo 09 (Circular Progress) for compact spaces, Demo 10 (Liquid Fill) for design-forward brand. Chat / messaging "other side is typing": Demo 16 (Typing Dots) — Discord/WhatsApp/iMessage pattern. Multi-step workflow (signup, checkout, onboarding): Demo 17 (Staircase) — shows step N of M. iOS / iPad feeling app: Demo 01 (Spinning Ring) matching iOS UIActivityIndicator. Material Design app: Demo 09 (Circular Progress) matching MUI's CircularProgress. Gaming / Web3 / esports brand: Demo 11 (Neon Arc Spinner) or Demo 07 (Glitch Flicker). Music player / audio app: Demo 13 (Wave Bars) — the audio-visualizer pattern. Scientific / biotech / data product: Demo 06 (DNA Helix) — visually communicates "processing data." Medical / wellness app: Demo 08 (Heartbeat Pulse). Astronomy / space / planetary app: Demo 15 (Orbit Planet). 3D-forward / WebGL adjacent brand: Demo 12 (Cube Flip 3D). Instagram-stories / progress-ring pattern: Demo 19 (Gradient Conic Spinner). Playful / branded / celebration moment: Demo 20 (Particle Burst) — when you want "loading" to feel like "something exciting is happening." Minimal / abstract / art-direction: Demo 14 (Morphing Square), Demo 18 (Infinity Loop). Dot-based variants: Demo 02 (Dot Chase), Demo 05 (Bouncing Balls) — small, low-emphasis indicators that don't dominate the viewport. All 20 demos: 100% Pure CSS, role="status" + aria-live="polite" + visually-hidden "Loading…" text out of the box, prefers-reduced-motion respected, MIT-licensed.