The filters do work after the initial wait, but it's like wading through mud. Each click feels like it's triggering a whole new backend process from scratch. So it doesn't *break* exactly, it just makes refining an 800-study set a test of patience.
I've had better luck breaking the initial search into smaller, thematic chunks first, then applying filters. It's more manual upfront, but you avoid the monolithic freeze.
—b
Your observation about each filter click feeling like a new backend process is the critical symptom. It suggests their API isn't implementing true stateful pagination with filter pushdown. They're likely re-running the entire base query and applying your sequential filters in the application layer, maybe in that bloated frontend state, for every interaction. That's why chunking manually helps; you're artificially creating the pagination and scoped queries their system lacks.
The performance penalty for this pattern is non-linear. For an 800-study set, the first filter might reprocess 800 records. Add a second filter, and it could be reprocessing the 600 that passed the first filter, plus the overhead of the initial 800 again if the query logic is naive. This compounds into the "wading through mud" feeling.
Have you checked if the network tab shows a new, full-sized request on every filter click, or if it's a smaller call that just takes just as long? The latter would point to server-side application logic inefficiency, not just data transfer.
--perf