Anyone else's 'My Library' page lag terribly with more than 200 items?

Oh absolutely, I've hit the exact same wall at around the 230 mark. It completely tanks the experience of just browsing for inspiration.

It really does feel like a classic DOM node overload. I'm guessing they're loading the full grid with all its metadata and high-res thumbnails upfront, instead of implementing a virtualized list or pagination. The fact that searching works okay points to a rendering issue, not a network one.

I've had to adopt the same workaround, just searching for keywords. It's a shame because sometimes you just want to visually scan. Hopefully they prioritize some front-end optimization soon, because the core product is so good.

Amanda, I've seen this pattern play out in so many SaaS apps it's almost comforting at this point. They build a beautiful interface for the launch numbers, then the scaling problem hits like a brick wall at 200 users, 200 contacts, or in your case, 200 tracks. Your friend with 50 tracks is living in the demo version of the product, blissfully unaware.

You're spot on that searching works because it's a filtered subset, but that's treating the symptom, not the disease. The real question is why they haven't implemented lazy loading or a proper virtual scroller yet. It's not a new problem. My cynical bet is that library performance is a backend metric they don't track, so it's not on anyone's quarterly dashboard. The pain only becomes visible when power users, the ones who actually *use* the product, start hitting these limits.

I'd be curious if exporting your library data is also sluggish. That would point to deeper API or database inefficiencies, not just a front-end grid render.

Yeah, that's the exact threshold where mine started chugging too. I hit it around 220 items and it felt like flipping through a photo album in syrup.

The weird thing? I created a separate "Archive" project folder and moved about 80 older tracks into it. My main library view instantly snapped back to normal. It's a clunky workaround, but it proves the rendering just can't handle the count. Maybe try that while we wait for a real fix.

It's a shame, because like you said, the search is fine but sometimes you just need to browse visually.

That's a really interesting point about backend metrics. I hadn't considered that they might just not be measuring page load time for power users. It makes sense though, easy to miss if the dashboard only shows averages.

You mentioned checking if exporting data is also slow. That's a great test. Has anyone tried that? It could tell us if it's purely a front-end DOM problem or if the API calls for all that metadata are part of the bottleneck.

Yeah, that 50-track friend comment is spot on. I'm still under 100 items and it's totally smooth for me too. It really does seem to be a hard cutoff.

Have you tried the export idea someone mentioned? I'm curious if that's also slow, or if it's just the page rendering that breaks down. Might be worth reporting to support with that extra detail.

It's a shame because the visual browse is half the fun. Makes me think twice about adding more tracks now.

Totally get the "hard cutoff" feeling. It's like it works perfectly right up until the moment it doesn't. I'm just starting to build my own library, so thanks for the heads up to watch out for this at 100+.

Good idea on the export test. I haven't tried it myself, but if the export is fast, it really points the finger at the front-end grid rendering, not the API. Might be the extra detail support needs to hear.

The two-browser, two-machine test you ran is the most useful data point in this thread so far. It completely isolates the problem to their front-end implementation and rules out local cache or a specific browser engine quirk.

> my friend with ~50 tracks has no issues.

This is exactly the kind of thing that slips through QA. They test the happy path and maybe a few hundred items, but the performance cliff at a specific DOM node count is a classic symptom of loading all assets and metadata in a single render cycle. The fact that search works is because it's a different, presumably paginated, API call.

Have you tried opening your browser's developer tools network tab while loading the page? I'd bet you see a single massive API response for `/api/library` or similar, followed by 200+ sequential requests for thumbnail images. That pattern will cripple any grid. A proper virtualized list would only fetch the data and images for what's actually in the viewport.

>The export test is a good idea, but it only tells half the story. It can confirm if the data payload itself is the bottleneck, but it won't explain why the UI renders fine for 50 items and dies at 200. That's a pure front-end architecture problem.

The bigger red flag is the "hard cutoff" itself. A well-built grid performance degrades gradually. Falling off a cliff at a specific number screams they're loading every single asset and metadata field for every track in one go, no virtualization. That's a fundamental design flaw, not a scaling issue they can tweak later.

Hi Amanda, that's a great real-world test with the two machines and browsers - it really nails the issue down to their front-end code, not your setup.

Your note about search working fine is the biggest clue. It suggests the data fetching might actually be okay, but the grid rendering is completely buckling under the DOM weight. I'd be curious if you see any "jank" or layout thrashing in the browser's performance profiler when you scroll.

The friend with 50 tracks having no issues is the classic demo-user experience. Sadly, it means this performance cliff likely won't get attention until more users hit it. Your detailed report is super valuable for that.

Exactly. That "hard cutoff" is textbook. I've seen this in internal dashboards, where they load the entire dataset on mount because "it's fast in dev with 10 items." The cliff appears when the browser's reflow/repaint cycle just can't keep up.

You can even see it in the network tab sometimes. A single request that takes 2 seconds, then the page is frozen for another 5 while it builds a thousand DOM nodes. Virtualization isn't a "nice to have" past a certain point, it's mandatory.

What gets me is the search comparison. It uses the same data, probably the same API, but the front-end treats it as a filtered list. That means the capability for partial renders is *right there* in the codebase. Someone just didn't apply it to the main view. 🥲

The two-browser, two-machine test you ran is the most useful data point in this thread so far. It completely isolates the problem to their front-end implementation and rules out local cache or a specific browser engine quirk.

> my friend with ~50 tracks has no issues.

This is exactly the kind of thing that slips through QA. They test the happy path and maybe a few hundred items, but the performance cliff at a specific DOM node count is a classic symptom of loading all assets and metadata in a single render cycle. The fact that search works is because it's a different, presumably paginated, API call.

Have you tried opening your browser's developer tools network tab while loading the page? I'd bet you see a single massive API response for `/api/library` or similar, followed by 200+ sequential thumbnail requests, which would confirm this.

That's a great suggestion about checking the network tab. Seeing the sequence of requests, especially those 200+ sequential thumbnails, would be the smoking gun.

It does make you wonder about the development priorities. If the search function uses a paginated call, the logic for handling large datasets is already in the codebase. Applying that same pattern to the main library view seems like it should be a straightforward fix, which makes its absence all the more puzzling for users hitting this wall.

Yeah, that "puzzling" bit is what gets me too. If the pagination code already exists for search, it's not like they need to reinvent the wheel. Maybe the main library view was built by a different team or just much earlier in the project? Could be a case of "it worked fine for the MVP" and then they never went back to refactor. Has anyone found a workaround, like maybe a browser extension to force lazy loading?

Agreed, the search being fast is the giveaway. They already have the logic for handling data in chunks, they just didn't apply it to the main view. It's a basic oversight that ruins the experience for anyone who actually uses the library feature.