The search uses a paginated component, sure, but the library view is probably built on a legacy list that no one wants to touch. Technical debt wins again.
Your fancy demo doesn't scale.
Your two-machine, two-browser test is the definitive piece of evidence here. It rules out everything but the front-end architecture.
The search performance comparison isn't just a clue, it's a blueprint. If the search API delivers paginated or filtered results that render smoothly, then the entire data-fetching and rendering pattern for handling large collections already exists in the codebase. The problem is purely that the main library view isn't using it.
To confirm the exact failure mode, open your browser's developer tools on the Network tab and reload your library page. I suspect you'll see one large initial JSON payload containing metadata for all 200+ tracks, followed by a waterfall of hundreds of sequential requests for every single thumbnail image. That combination of a large synchronous render and unthrottled asset loading is what creates that "hard cutoff" you're experiencing.
Trust but verify.
You're right about the performance cliff being a classic sign of loading everything upfront, but the sequential thumbnail requests are only half the problem. The real killer is often the synchronous processing that happens after the data arrives.
Even if the thumbnails were batched or lazy loaded, rendering 200 complex list items in a single JavaScript turn can still lock the main thread for seconds. The profiler would show a massive Layout/Recalculate Style block. Search avoids this because its paginated results trigger smaller, discrete renders.
So the network tab shows the symptom, but the Performance tab's flame chart would reveal the actual disease, a single blocking task that chokes the event loop.
—davidr
> Once my library grew past the 200-track mark, the page became almost unusable.
That's the signature of a frontend performance cliff. Your two-browser, two-machine test is perfect - it isolates the problem to the application's rendering logic.
The fact that search works smoothly is the real proof. It means the infrastructure for pagination or virtualization is already in the codebase. Someone just didn't wire it up for the main library view. It's a classic case of a component built for an MVP that never got refactored when usage grew.
To confirm, check your browser's Performance tab while loading the page. You'll likely see one massive, long "Layout" or "Recalculate Style" task after the data loads. That's the main thread being blocked while it tries to paint 200+ items at once. Search avoids this by rendering in smaller chunks.
Sleep is for the weak
Your two-machine, two-browser test is the critical data point. It rules out local issues and confirms it's their rendering logic.
Check the browser's Performance tab. I'd wager the flame chart shows a single, massive layout or paint task blocking the main thread after the data loads. That's the performance cliff.
The fact that search works confirms the fix is already in their codebase. They just didn't apply it to the library view.
Five nines? Prove it.
I'm seeing the same issue and it's frustrating. The fact that your friend with 50 tracks has no problem is the final proof it's a scaling issue. I have about 180 tracks and it's already starting to get sluggish. Makes you wonder if the product team even tests with full libraries. Have you submitted a support ticket? I'm hesitant to renew my subscription if basic navigation is this bad.
Your point about the search performance being a telltale sign is spot on. It's not just about proving it's a front-end issue, it's about identifying the specific architectural decision, or lack thereof.
That separation indicates the library view likely predates the search implementation. Search was probably built later with modern practices when the performance requirements for handling large result sets were clear. The original library view, deemed "good enough" at a smaller scale, was left untouched.
It becomes a procurement concern. When evaluating a vendor's roadmap, you have to ask if they have a process for retiring technical debt, or if new features are just layered on top of brittle foundations. This kind of neglect in a core user interface is a red flag for long-term platform stability.
Exactly. That architectural split you're describing screams "feature teams vs platform teams" to me. The search team probably had a clear performance KPI and built a modern, paginated service. Meanwhile, the library team is stuck maintaining the old monolith and can't get the refactor onto the roadmap because it's seen as "just a UI polish," not a new feature.
It's the classic problem: the metrics that get measured get fixed. No one's measuring "time to interactive on the library page for power users," so it never gets prioritized. Makes you wonder what other parts of the platform are held together by legacy code that hasn't hit its breaking point yet.
Data nerd out