If the homepage felt slow to open — especially on an older laptop — that was a real bug, not your machine. The catalog table is supposed to render only the rows currently on screen (a few dozen) and recycle them as you scroll. Instead it was rendering all ~3,300 rows at once, every time, which locked up the page for several seconds before anything appeared.
It's fixed. On a low-end laptop the table now shows up in a second or two instead of ten, and scrolling and filtering are smooth again.
Under the hood
The table uses windowed virtualization, which needs a scroll container with a known height to figure out what's actually on screen. A CSS height chain had silently collapsed — a flex-1 grew past an explicit height: calc(100vh - 200px) whose ancestors had no real height — so the virtualizer measured its viewport as the entire content height and concluded every row was visible. Result: ~66,000 cells mounted in one synchronous render. Measured on an i5-6200U: 3,308 rows in the DOM, ~3.2 s of main-thread blocking, first row painted at ~4.6 s.
The fix switches to window-based virtualization (the page scrolls, the sidebar stays put — as it was meant to) and drops the fragile magic number entirely. Rows in the DOM went from 3,308 to about 26; blocking time from ~3,200 ms to ~280 ms. The remaining wait is now just the network fetching the data — which is the next thing on the list to trim.