Stop hiding stale data in live search

July 11, 2026 Rens Jaspers UX Webdev Search Performance

One UX mistake keeps showing up in live search bars.

If your search starts automatically while the user is typing, don't replace the current results with a loading spinner.

Take Netflix (July 2026) as an example.

What it gets right:

  • Search is debounced. It waits roughly 300 ms after typing stops before sending a request.

What it does wrong:

As soon as a search starts, the existing results disappear and are replaced by a loading spinner. The user has no choice but to wait.

Even worse, searches that should almost certainly be cached still trigger another fetch.

Try this:

  1. Search for "James" and wait for the results.
  2. Type "James Bond".
  3. Press Backspace until you're back to "James".

Instead of instantly showing the previous results, Netflix fetches them again while showing only a spinner.

For something like a movie catalog, this is unnecessary. Search results can usually be cached for minutes, if not hours.

Why this matters

This becomes especially frustrating on slower devices, slower networks, or for people who type more slowly—exactly the environments where live search is common, such as smart TVs and smartphones.

A typical interaction looks like this:

  • You type a few letters.
  • You pause briefly to think or because the device is slow.
  • The debounce timer expires and a search starts.
  • You briefly see useful partial results.
  • Just as you're about to click one, they disappear behind a loading spinner.
  • A second later, different results appear.
  • Now you have to press Backspace and wait all over again.

The UI actively gets in the user's way.

A better approach

The fix is straightforward.

  • Keep showing stale results while fresh data is loading.
  • Show a small spinner or indeterminate progress indicator next to the results so users know an update is in progress.
  • Don't fade the stale results. Lower opacity hurts accessibility and suggests the items are temporarily unavailable, even though they're still perfectly clickable.
  • Cache search results for at least a minute so users can move back and forth without unnecessary network requests.
  • Combine debounce with distinctUntilChanged(). If a user types "James", continues to "James Bond", then immediately backspaces back to "James", don't cancel the original "James" request just to start another identical one. This matters even when caching exists, because the first request may still be in flight.

Good live search should feel instant.

If you already have useful data on screen, don't hide it while you're fetching slightly newer data.