Top Loading Indicators Compared: nprogress vs react-loader-spinner vs react-top-loading-bar

When users wait for content, a well-designed loading indicator reduces perceived latency and improves UX. The three libraries — nprogress, react-loader-spinner, and react-top-loading-bar — all address this need but with fundamentally different approaches: global top bar, inline spinners, and React-native top bar, respectively. Let’s compare them in real engineering contexts.

📏 Visual Pattern and Placement

nprogress renders a thin, colored bar fixed at the very top of the viewport (position: fixed; top: 0). It mimics the native browser loading bar seen in Chrome.

// nprogress: Imperative global control
import NProgress from 'nprogress';

NProgress.start();
fetch('/api/data').then(() => NProgress.done());

react-loader-spinner provides reusable React components that render inline wherever placed in the JSX tree — inside a button, a card, or a full-screen overlay.

// react-loader-spinner: Declarative inline spinner
import { Oval } from 'react-loader-spinner';

function LoadingCard({ isLoading }) {
  return (
    <div>
      {isLoading ? <Oval height={40} width={40} /> : <Content />}
    </div>
  );
}

react-top-loading-bar also renders a top-of-page bar like nprogress, but as a React component that lives in your app’s JSX hierarchy.

// react-top-loading-bar: Component-based top bar
import TopLoadingBar from 'react-top-loading-bar';
import { useRef } from 'react';

function App() {
  const ref = useRef(null);

  const startLoading = () => ref.current?.continuousStart();
  const finishLoading = () => ref.current?.complete();

  return (
    <>
      <TopLoadingBar color="#29D" ref={ref} />
      <MainApp startLoading={startLoading} finishLoading={finishLoading} />
    </>
  );
}

⚙️ Integration Model: Imperative vs Declarative

nprogress is imperative and global. You call NProgress.start() and NProgress.done() directly. This works outside React but creates tight coupling to side effects.

// Common in route guards
router.beforeEach((to, from, next) => {
  NProgress.start();
  next();
});

router.afterEach(() => NProgress.done());

react-loader-spinner is purely declarative and local. You conditionally render the spinner based on React state. No global state or side effects.

function SubmitButton({ isSubmitting }) {
  return (
    <button disabled={isSubmitting}>
      {isSubmitting ? <TailSpin height="20" width="20" /> : 'Submit'}
    </button>
  );
}

react-top-loading-bar blends both: it’s declarative in structure (you render the component once) but imperative in control (you call methods via a ref). This gives you the visual style of nprogress with React lifecycle safety.

// Safe for SSR — no direct DOM access in render
useEffect(() => {
  loadingRef.current?.continuousStart();
  fetchData().finally(() => loadingRef.current?.complete());
}, []);

🧪 Server-Side Rendering (SSR) and Testing

nprogress manipulates the DOM directly on import. This breaks in SSR environments like Next.js unless you guard usage with typeof window !== 'undefined'.

// Risky in SSR
if (typeof window !== 'undefined') {
  NProgress.start();
}

react-loader-spinner is fully compatible with SSR because it renders standard React elements. No DOM access during render.

// Safe everywhere
<Oval ariaLabel="loading-indicator" />

react-top-loading-bar avoids DOM access during initial render and uses refs for runtime control, making it SSR-safe by design.

// Renders empty div on server, activates on client
<TopLoadingBar color="#f00" ref={ref} />

🎨 Customization and Animation Control

nprogress allows limited customization via CSS overrides or a config object:

NProgress.configure({
  minimum: 0.1,
  showSpinner: false,
  speed: 500
});

But you can’t change the core animation logic without forking.

react-loader-spinner offers multiple built-in spinner types (Oval, Circles, TailSpin, etc.), each accepting props like height, width, color, and ariaLabel. You can even pass custom SVG paths.

<Puff
  visible={true}
  height="80"
  width="80"
  color="#4fa94d"
  ariaLabel="puff-loading"
/>

react-top-loading-bar supports color, height, and shadow via props, plus programmatic control over progress simulation (continuousStart, staticStart, complete).

<TopLoadingBar
  color="#29D"
  height={3}
  shadow={true}
  ref={ref}
/>

🔄 Real-World Usage Scenarios

Scenario 1: SPA Route Transitions

You’re using React Router and want a top bar during page loads.

• ✅ Best: react-top-loading-bar — integrates cleanly with React lifecycle and router hooks.
• ⚠️ Alternative: nprogress — works but requires useEffect guards and isn’t React-idiomatic.
• ❌ Not suitable: react-loader-spinner — wrong visual pattern (inline, not top bar).

Scenario 2: Form Submission with Inline Feedback

A user clicks “Save” and you show a spinner inside the button.

• ✅ Best: react-loader-spinner — designed exactly for this.
• ❌ Not suitable: Both top-bar libraries — they occupy global screen space unnecessarily.

Scenario 3: Dashboard with Multiple Async Widgets

Each widget loads independently and shows its own loading state.

• ✅ Best: react-loader-spinner — per-widget spinners avoid visual noise from a single top bar.
• ⚠️ Possible but awkward: Top-bar libraries would require complex coordination to avoid flickering.

📌 Summary Table

💡 Final Recommendation

• Need a top bar and aren’t using React? → nprogress.
• Building a React app and want a top bar? → react-top-loading-bar.
• Need inline, contextual spinners? → react-loader-spinner.

Don’t mix top bars and inline spinners arbitrarily — pick one primary loading pattern per app to maintain visual consistency. And always ensure loading states are accessible (e.g., with aria-busy or aria-live regions), regardless of which library you choose.