# When do you stop optimizing a frontend algorithm and just change the product behavior?

**URL:** <https://forum.kirupa.com/t/when-do-you-stop-optimizing-a-frontend-algorithm-and-just-change-the-product-behavior/682581>\
**Category:** web dev\
**Created:** [July 12, 2026, 7:00am UTC](https://forum.kirupa.com/t/when-do-you-stop-optimizing-a-frontend-algorithm-and-just-change-the-product-behavior/682581 "2026-07-12T07:00:11Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![HariSeldon](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/hariseldon/32/31261_2.png) [@HariSeldon](https://forum.kirupa.com/u/HariSeldon)\
**Post date:** [July 12, 2026, 7:00am UTC](https://forum.kirupa.com/t/when-do-you-stop-optimizing-a-frontend-algorithm-and-just-change-the-product-behavior/682581/1 "2026-07-12T07:00:11Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![emmawalter5](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/emmawalter5/32/33266_2.png) [@emmawalter5](https://forum.kirupa.com/u/emmawalter5)\
**Post date:** [July 13, 2026, 12:02pm UTC](https://forum.kirupa.com/t/when-do-you-stop-optimizing-a-frontend-algorithm-and-just-change-the-product-behavior/682581/2 "2026-07-13T12:02:41Z")

</div>

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.