I watched a search box die in the most boring way possible.
Three letters. The caret blinked, considered its options, and then the results showed ...
For further actions, you may consider blocking this person and/or reporting abuse
The 50 ms cutoff is a diagnostic threshold, not a frame budget. At 60 Hz a frame has roughly 16.7 ms for all its work, so repeated 49 ms slices can still feel choppy without producing a single Long Task entry. For this demo, comparing 50 ms and 8 ms slice budgets with the same rAF marker would expose that difference nicely. The right budget depends on the device and the work left for layout/paint; staying below 50 ms alone does not mean the UI meets its frame budget.
Good catch — 50ms is the diagnostic line for a long task, not the frame budget. If the page also animates, I watch real frame times alongside the long-task entries; the yield keeps input responsive, but 16.7ms is the separate check. Thanks for spelling that out.
Yeah, that's a fair correction. Fifty milliseconds is just the line where a task gets called "long." A frame at 60 Hz only has about 17 ms, so a bunch of 49 ms slices can still feel bad and never show up as a Long Task.
The demo stops at that line, which is enough to show the difference against one 500 ms block. It doesn't mean the UI is actually hitting its frames. An 8 ms slice next to the same marker would make that obvious.
The one nuance I would add: debounce and yield are not rivals. Debounce reduces the total work by skipping searches nobody will ever see, while yielding keeps each chunk under the 50 ms long-task line. The rude part was never the timer, it was running the whole filter as a single task.
Agreeed 💯
Glad it landed. The combo I keep reaching for is a 150ms debounce on the input event, then yield every ~50ms inside the filter loop with one AbortController per run, so stale searches get killed the moment you type again.
Slow versus rude is doing a lot of work in this piece and it holds up.
One case worth separating though. When the index lives on a server or a hosted search service, the long pole isn't scripting at all, it's the round trip. Debounce there isn't hiding a bug, it's load control: without it you fire three or four requests per word typed, and on a metered service that's the bill as well as the latency. Same line of code doing a completely different job depending on where the work happens. Most of its bad reputation comes from being pasted in as a cure before anyone made the diagnosis.
On hunting the longest task in production, ours wasn't ours. The worst offender for months was a tag manager container doing its own work on the main thread, and no amount of yielding in our code went near it. Worth auditing the third party scripts before refactoring your own loop.
To answer the closing question honestly, I don't know for the build we shipped this week. Which is the answer your last line already predicts.
Yeah, that's fair. I was talking about the filter that already lives on the main thread. If the search is a request, debounce is just you not firing four of them per word, and that's a different job.
The tag manager one stings a bit. We spent a while yielding our own loop once and the long task was a container we didn't even own. Worth checking that before touching the code.
scheduler.yield() keeping user-visible priority while setTimeout(0) drops to the back of the macrotask queue is the distinction I wish more "just yield" posts spelled out. Pairing that with abort-after-wake is what actually stops the polite slideshow of stale results.
yeah, exactly. yielding makes old work less blocking, but aborting it is what stops stale searches from coming back and doing a polite little slideshow.
the post-yield abort check matters most. that is the point where an older search wakes up and realizes the user has already moved on.
One extra tradeoff with the setTimeout(0) fallback: repeatedly awaiting it between chunks creates a nested timer chain, which eventually hits the browser's 4ms minimum delay. The time budget controls how much work happens before yielding, but doesn't remove that wait. Smaller chunks can therefore improve responsiveness while increasing total completion time, especially when the work in each chunk is short compared with the timer delay.
the INP point is the one that gets missed. debounce arms a timer, the interaction returns instantly, the dashboard stays green, and the long task still lands a third of a second later. we hit this on a table filter and only caught it by looking at long animation frames in field data, not lab runs. the setTimeout fallback for Safari worries me a bit though, since it yields but without any priority. are you chunking by a time budget or by row count?
the point that INP stays green because a timer is not an interaction is the sharpest bit here. we had the same thing, debounce moved the freeze to just after the pause and the dashboard never flagged it. what fixed it for us was a deadline loop like your 50ms one with an abort signal, plus watching long task entries in the field instead of trusting INP alone.
with safari still on the setTimeout fallback, did you see results dribble in noticeably slower there, or is it fine in practice?
Yeah, exactly. Debounce made the chart look calmer without making the page feel calmer.
On Safari, it was fine in the demo because I only painted once at the end, so the results did not visibly dribble in. The difference is mostly in scheduling:
setTimeout(0)gives up the thread, but it comes back through the regular task queue—not withyield()’s “let urgent input go first” behavior.For a heavier real UI, I’d use a smaller slice budget there and still abort aggressively. The fallback keeps the page usable; it just does not give the same priority guarantees.