Build search-as-you-type that stays responsive without lagging the input

You are implementing a search-as-you-type input in React. You choose between useDeferredValue, manual debouncing, or a combination of both based on where the actual cost of each keystroke lives — in expensive client-side rendering, in a network request, or in both — rather than reaching for whichever one you used last time.

SEARCH BEHAVIOR
A command-palette style search over a list of 3,000 in-app actions, filtered client-side as the user types.

DATA SOURCE
Fully client-side — all 3,000 actions are loaded once at app start and kept in memory.

LATENCY BUDGET
Input must never visibly lag on any keystroke; results can lag the keystroke by up to roughly 100ms without feeling broken.

CURRENT IMPLEMENTATION
A single useState for the query, filtering the full 3,000-item array inline in the render body on every keystroke — noticeably laggy on older laptops.

SELECTION RULES
If the cost is entirely in client-side rendering — filtering or sorting a large already-loaded array on every keystroke — use useDeferredValue on the search term and render the expensive list against the deferred value, not the raw input value. This keeps the input itself always responsive because React can interrupt and deprioritize the expensive re-render triggered by the deferred value without ever blocking the actual keystroke from appearing; it does not delay when the underlying value updates, only when the expensive re-render is allowed to catch up to it. If the cost is in a network request, useDeferredValue alone does not help — it does not reduce how many requests fire, since the value itself still updates on every keystroke. Add an actual debounce on the value used to trigger the fetch, so a request only fires after typing pauses for the given interval, and cancel any in-flight request that a newer keystroke has superseded so a slow, stale response can never overwrite a faster response to a more recent query. If both a large in-memory dataset and a network refinement are involved, combine them: debounce the network trigger, and separately use useDeferredValue for the render itself so the input never stutters while either the debounce timer or the network request is pending. Show an isPending or isStale indicator during the deferred or debounced window so the user can tell displayed results might not yet reflect their latest keystroke, rather than silently presenting possibly-outdated results as current. Never wrap the input's own value in useDeferredValue or a debounce — the character the user just typed must render in the input on every keystroke with zero delay regardless of which mechanism is deferring the expensive work downstream; deferring or debouncing the input's own displayed value, rather than only the value used to drive the filter or the fetch, is what actually causes the perceptible typing lag this whole prompt exists to prevent.

OUTPUT FORMAT
1. Which mechanism or combination you chose and the specific reason tied to where the cost actually lives.
2. The implementation, as real code, including request cancellation if a network call is involved.
3. What the stale/pending indicator looks like and exactly when it appears and disappears.