React Dashboards That Stay Fast at 10,000 Rows

Admin panels and operations dashboards start fast. Then the data grows: a few hundred rows become ten thousand, filters multiply, and every keystroke in the search box makes the whole screen stutter. The good news is that dashboards get slow in predictable ways, and each one has a well-known fix.

Render only what's on screen

A table with 10,000 rows doesn't need 10,000 DOM rows — the user can see maybe thirty. List virtualisation renders the visible window plus a small buffer and swaps rows as you scroll.

• Use a fixed or measured row height so scroll position stays accurate
• Keep row components small and pure
• Give every row a stable key from the data, never the array index

This single change usually turns an unusable table into a smooth one.

Move filtering and sorting to the server

Shipping the entire dataset to the browser and filtering there works until it doesn't. Paginate on the server, and send filters, sort order and page as query parameters.

If the browser is doing database work, the database isn't doing its job.

Put those parameters in the URL too. Filters then survive a refresh, and a link to "overdue invoices, sorted by amount" can be shared with a colleague.

Stop re-rendering the whole page

Most dashboard jank comes from state that lives too high in the tree.

1. 01Keep fast-changing state — search input, hover, open menus — local to the component that uses it
2. 02Debounce search input by around 250 ms before triggering a request
3. 03Memoise expensive derived data with useMemo, keyed on the inputs that actually change it
4. 04Split large contexts so a change in one value doesn't re-render every consumer

Measure before you optimise

Open the React DevTools Profiler, record an interaction and look at what re-rendered and why. It's common to find one context provider re-rendering the entire app on every keystroke.

Treat server data as a cache

Use a data-fetching library such as TanStack Query rather than hand-rolled useEffect fetches. You get request de-duplication, background refresh, cached pages when moving back and forth, and loading states for free.

Charts need limits too

A line chart with 50,000 points is both slow and unreadable. Aggregate on the server — per hour, per day — and let users zoom in for detail. Your users want the trend, not every point.

The checklist

• Virtualise long lists
• Paginate, filter and sort on the server
• Keep fast state local and debounce inputs
• Cache server data with a query library
• Aggregate before charting

Apply these early and a dashboard can grow from a hundred rows to millions without a redesign.