TPToolpazar

Global Araç

Css Loader Generator

CSS

.loader {
  width: 48px;
  height: 48px;
  border: 4px solid #0f766e40;
  border-top-color: #0f766e;
  border-radius: 50%;
  animation: loader-spin 1s linear infinite;
}
@keyframes loader-spin {
  to { transform: rotate(360deg); }
}

HTML

<div class="loader"></div>

A loading spinner is the smallest UX element on a page that has the biggest job: tell the user the system is alive, working, and worth waiting for. Done well, a spinner reduces perceived wait time (research from Microsoft’s UX team shows that users consistently rate progress-indicated waits as 30-40% faster than unindicated ones of identical actual duration). Done badly — too big, wrong color, jittery animation — it either annoys users or signals unprofessionalism. Pure-CSS loaders are the modern default: zero JavaScript, zero image assets, scale-and-color customizable through variables, and they cost essentially nothing in bundle size and render performance.

The generator produces five proven spinner patterns: classic spinner (rotating partial circle, the iOS / Material default), three bouncing dots (TikTok / Instagram chat style), pulse (single circle scaling in/out, calmest visual), bars (staggered vertical bars rising/falling, audio-meter aesthetic), and concentric ring (clean two-layer rotating ring, popular in fintech UIs). Each is built with a single HTML element plus a CSS class — no library required. Adjust color (your brand palette), size (16px for inline, 32px standard, 64px hero loaders), and animation duration (0.8s default; 1.2s feels calmer; 0.4s feels urgent).

Implementation notes: all five loaders use @keyframes for animation, CSS custom properties (--spinner-size, --spinner-color) for theming, and rely only on transform and opacity for animations — both GPU-composited properties that don’t cause layout reflows. That means the spinner runs at 60fps even on slow devices and during heavy main-thread work (which is exactly when you’re showing a spinner). For accessibility, wrap in a prefers-reduced-motion media query so users who request reduced motion see a static indicator instead of perpetual rotation.

Nasıl Kullanılır

  1. Pick one of the five loader styles (spinner, dots, pulse, bars, ring).
  2. Customize color (hex or CSS variable), size (16-64px), and animation speed (0.4-1.5s).
  3. Copy the CSS into your stylesheet and the HTML snippet into your component.
  4. Wire up show/hide logic in your JS (display:block during fetch, display:none after).
  5. Wrap @keyframes in a prefers-reduced-motion: no-preference media query for accessibility.

Ne Zaman Kullanılır

  • Loading states for fetch/XHR calls that take 200ms or more.
  • Form submission feedback while waiting for server response.
  • Image gallery loading or skeleton fallback during async asset loads.
  • Initial app boot before client-side router hydrates.
  • Modal/sidebar content loading after a click action.

Ne Zaman Kullanılmaz

  • Sub-100ms operations — flash spinners create perception that something’s wrong; just wait, no indicator.
  • Truly long operations (>10 seconds) — use a real progress bar with percentage instead of an indeterminate spinner.
  • When you can show a skeleton (gray placeholder shape of the actual content) — always better UX than a spinner.
  • When the actual content can render progressively — stream it instead of holding everything behind a spinner.

Yaygın Kullanım Senaryoları

  • Verifying a number or output before passing it on
  • Quick generation during a typical workday
  • Pre-decision sanity-check on inputs and outputs
  • Educational use &mdash; demonstrating the underlying concept

Sık Sorulan Sorular

Does this work with prefers-reduced-motion?

Out of the box, no — but you can wrap the @keyframes block in @media (prefers-reduced-motion: no-preference) { ... } so users who’ve set reduced-motion in their OS see a static indicator. WCAG 2.1 doesn’t require reduced-motion support but it’s strongly recommended; some users get vestibular discomfort or seizures from continuous motion.

Will it work in old browsers?

@keyframes and transforms are universally supported in all modern browsers (Chrome 4+, Firefox 16+, Safari 9+, Edge all versions). For IE11 you’d need vendor prefixes (-webkit-, -ms-) for transform and animation. The generator typically outputs unprefixed modern CSS — add an autoprefixer step in your build if you support legacy browsers.

Performance impact of the spinner?

Negligible. Pure CSS animations using transform/opacity run on the GPU compositor thread, separate from the main JavaScript thread. They render at 60fps even when your JS is blocking. The whole loader (HTML + CSS) is typically <500 bytes minified.

Can I add accessibility text?

Yes and you should. Wrap the spinner in a div with role="status" and aria-live="polite", then include visually-hidden text like “Loading…” inside. Screen readers announce the status; sighted users see the spinner. Example: <div role="status"><div class="spinner"></div><span class="sr-only">Loading</span></div>.

Should I use SVG instead?

Both work. SVG has slightly more flexibility for complex shapes and can use SMIL animation. CSS-only loaders are simpler to maintain, theme via CSS variables, and don’t need extra files. For the five common patterns, CSS is the cleaner choice. For brand-specific complex spinners (custom logo morphing), SVG is more flexible.

When should I show a skeleton screen instead?

Always when feasible. Skeleton screens (gray placeholder shapes that match the eventual content layout) show 25-40% lower perceived wait times than spinners in research studies because they hint at progress and give the eye something structured to look at. Use spinners only when you genuinely don’t know what the content will look like (search results before query is sent, mostly).