Technical

The API Responds in 200ms, But the Spinner Lasts 3 Seconds — Where Did the Time Go?

RU
Rishabh UpadhyaySoftware Engineer & Designer

When Fast APIs Feel Slow

"The API responds in 200ms… but the spinner lasts 3 seconds."

So where does the remaining 2.8 seconds actually go?

This gap is the difference between system performance and user-perceived performance — and it's where most UX issues hide.

Let's break down what really eats up that invisible time

Performance vs Perception

From the backend's point of view:

  • The API is fast
  • The request completed successfully
  • Metrics look healthy

From the user's point of view:

  • The app feels slow
  • The spinner keeps spinning
  • Something feels broken

Both can be true at the same time.

Before the Request Even Starts

Latency doesn't begin at the API.

Before a request is sent, time can already be lost to:

  • DNS lookup
  • TCP connection setup
  • TLS handshake
  • Cold starts (serverless, edge functions)
  • Slow mobile networks or packet loss

None of this shows up in your API response time.

After the API Responds

The backend may be done — but the work isn't.

Common post-response bottlenecks include:

  • Large JSON payloads that take time to parse
  • Heavy client-side validation
  • Data transformations on the main thread
  • State updates triggering unnecessary re-renders

The API returned quickly. The client is still busy.

Rendering and UI Bottlenecks

This is where most "fast backend, slow app" bugs live.

Typical issues:

  • Blocking JavaScript during hydration
  • Large JS bundles delaying first paint
  • CSS recalculation and layout thrashing
  • Images, fonts, or icons loading late

Rendering is expensive — especially on low-end devices.

Intentional Delays (Yes, These Exist)

Some delays are added on purpose.

For example:

  • Minimum spinner display time (to avoid flicker)
  • Artificial delays for "smoothness"
  • Coordinated animations or transitions

These may improve aesthetics — but they still count toward perceived slowness.

Visualizing the Timeline

Code
User Action
 ↓
 Network setup (DNS, TCP, TLS)
 ↓
 API request (200ms) ← Your metric sees this
 ↓
 Response parsing (JSON decode)
 ↓
 State updates (Redux, Context, etc.)
 ↓
 Re-renders (React, Vue reconciliation)
 ↓
 Hydration & layout
 ↓
 UI finally updates ← User sees this

Only one small part of this is the API.

The Real Lesson

Backend metrics can say "everything is fast." Users can still experience "the app is slow."

Optimizing one layer in isolation rarely fixes the problem.

What You Actually Need to Measure

To understand real performance, you must look beyond API timing:

| Metric | What It Measures | |--------|------------------| | TTFB | Time to First Byte (network + server) | | FCP | First Contentful Paint (when user sees content) | | LCP | Largest Contentful Paint (main content visible) | | INP | Interaction to Next Paint (measures responsiveness across all interactions) | | CLS | Cumulative Layout Shift (visual stability) | | TTI | Time to Interactive (app fully responsive) |

Network waterfall charts JavaScript execution time Render and hydration cost

If you don't measure these, you're guessing.

Why This Matters

Most performance work fails because teams optimize:

  • What's easy to measure
  • Not what users feel

A fast API is a good start.

A fast experience is the real win.

Final Takeaway

If you've ever chased a "slow app" only to discover the API was innocent — you already know this pain

Performance is not a single number. It's a pipeline.

And users feel the slowest part, not the fastest.

Related Topics

Want to dive deeper? Consider exploring:

  • Web Vitals deep dive (LCP, FID, CLS)
  • Waterfall diagram analysis
  • Frontend vs backend performance checklists
  • Mobile-first optimization strategies
Continue Reading