What is `useDeferredValue` and how does it differ from debouncing?

Q: What is `useDeferredValue` and how does it differ from debouncing?

**Target Audience:** Engineers preparing for senior React interviews — assumes hooks and memoisation basics. **Difficulty:** Hard > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every render count below was **executed against React 19.2.8**, including the head-to-head against a real debounce — the raw numbers are in section 4. Related: what transitions do under the hood , which is the same scheduler seen from the other end. ## 1. Why This Even Matters — A Story First Two ways to handle a colleague who sends you a message every few seconds while thinking out loud. **Debouncing:** ignore everything until they have been quiet for two seconds, then read only the last message. Efficient — and you miss every intermediate thought, and you sit there doing nothing during the pause. **Deferring:** read every message, but only when

01

Understand the problem

Question presented to candidate: "A search box re-renders an expensive result list on every keystroke. Would you debounce it or use useDeferredValue, and what is the actual difference?"

What a strong answer should cover:

useDeferredValue returns a lagging copy of a value. The component renders twice per change: once with the new value and the old deferred one, then again once React catches up.
Debouncing delays the state update itself. Values in the middle of a burst are never processed at all.
So the trade is: deferring processes every value, late; debouncing processes fewer values, later.
Deferring is interruptible and adaptive — it yields to urgent work and keeps up on a fast machine — where a debounce is a fixed timer that is wrong on both fast and slow devices.
With a debounce the UI shows stale content for the whole delay, including after the user has stopped typing.
useDeferredValue needs the expensive child to be memoised, or it re-renders anyway and the deferral buys nothing.
Debouncing is still correct for things with a cost per call — network requests, analytics, autosave. Deferring is for render cost.

Clarifying questions expected:

"Is the expensive part rendering, or a network request?" — that alone decides which tool.
"Is the result list already memoised?"

Code / implementation expected: Optional. A one-line useDeferredValue plus a memo wrapper is enough to show the shape.

reactconcurrentperformance

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for senior React interviews — assumes hooks and memoisation basics. Difficulty: Hard

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every render count below was executed against React 19.2.8,

Solution ready — 2 min read

Classified // press E to declassify

04

Explore the playground snippets

Deferred against debounced, side by side

Run Playground

import { useState, useMemo, useEffect, useRef, useDeferredValue, memo } from "react";

const ROWS = Array.from({ length: 800 }, (_, i) => "Result " + i);

// A deliberately expensive, memoised child. The memo wrapper is not a
// nice-to-have here — without it, deferring buys nothing.
const Results = memo(function Results({ query }) {
  const rows = useMemo(() => {
    const out = [];
    for (const r of ROWS) {
      let acc = 0;
      for (let i = 0; i < 300; i++) acc += i % 5;
      if (acc >= 0 && r.includes(query)) out.push(r);
    }
    return out;
  }, [query]);

  return (
    <div style={{ fontSize: 12, color: "#444" }}>
      showing <strong>{rows.length}</strong> rows for {JSON.stringify(query)}
    </div>
  );
});

function Deferred() {
  const [text, setText] = useState("");
  const deferred = useDeferredValue(text);
  const stale = text !== deferred;      // the idiomatic staleness check
  return (
    <Panel title="✅ useDeferredValue" value={text} onChange={setText} stale={stale}>
      <Results query={deferred} />
    </Panel>
  );
}

function Debounced() {
  const [text, setText] = useState("");
  const [settled, setSettled] = useState("");
  const timer = useRef(null);
  useEffect(() => {
    if (timer.current) clearTimeout(timer.current);
    timer.current = setTimeout(() => setSettled(text), 300);
    return () => clearTimeout(timer.current);
  }, [text]);
  return (
    <Panel title="⏱ debounce(300ms)" value={text} onChange={setText} stale={text !== settled}>
      <Results query={settled} />
    </Panel>
  );
}

function Panel({ title, value, onChange, stale, children }) {
  return (
    <div style={{ border: "1px solid #ddd", borderRadius: 8, padding: 12, marginBottom: 12 }}>
      <strong style={{ fontSize: 13 }}>{title}</strong>
      <input
        value={value}
        onChange={(e) => onChange(e.target.value)}
        placeholder="type: 1, then 12, then 123"
        style={{ width: "100%", margin: "6px 0" }}
      />
      <div style={{ opacity: stale ? 0.45 : 1, transition: "opacity 120ms" }}>{children}</div>
    </div>
  );
}

export default function App() {
  return (
    <div style={{ padding: 24, fontFamily: "system-ui", lineHeight: 1.6, maxWidth: 520 }}>
      <Deferred />
      <Debounced />

      <p style={{ fontSize: 13, color: "#666" }}>
        Type a few characters quickly in each, then stop. The deferred panel is
        never more than one render behind — it dims briefly and catches up. The
        debounced panel keeps showing the result for whatever you had typed
        300ms ago, and only catches up once you stop entirely. Fewer renders,
        more staleness.
      </p>
    </div>
  );
}

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.