Hey folks, I’m working on a search-as-you-type picker in a React app and I’m trying to keep it snappy on low-end laptops while the dataset can spike from 5k to 200k items.
Right now we do fuzzy matching + scoring on each keystroke and even with debouncing it sometimes locks up the main thread; indexing helps memory but makes updates slower and adds complexity. How do you decide the cutoff where you stop chasing algorithm tweaks and instead change UX (server-side search, minimum chars, pagination, “press Enter to search”) to keep a performance budget predictable?
At 200k items, I would consider change the architecture instead of getting a few more milliseconds out of the algorithm. A golden rule is to profile first: if most of the time is spent doing things that you can’t really optimize out then it’s time for a UX change.
I typically go through this series:
Up to a few thousand items: OK to do a fuzzy search on the client.
Tens of thousands: pre-indexing, virtualizing, Web Workers and incremental updates.
Hundreds of thousands: Server side search or a hybrid of searching with a minimum character threshold (2-3 chars) and limits on results.
Many times, people overlook this middle ground where they move the search into a Web Worker, so that the UI remains responsive even if the search itself takes 100–200 ms.
I would also fix a performance budget (no drop frame or <100ms user perception after typing). When I see that I need to get increasingly complex optimizations to fulfill that budget, I know it’s time to change the UX rather than the algorithm.
