Enterprise frontends often fail performance reviews in a misleading way. The UI looks like the culprit because that is where the lag is visible, but the actual problem is frequently the contract between browser and backend.
In one manufacturing platform I rebuilt large-dataset views around React 18, TypeScript and RTK Query and moved pagination, sorting and filtering to the server. In representative views measured with Chrome DevTools, browser memory consumption dropped by roughly 70%.
The interesting part was not a clever memoization trick. It was removing work the browser should never have received.
A table is a distributed feature
A serious data grid spans at least four layers:
- query semantics in the API;
- database filtering and ordering;
- cache identity in the client;
- rendering and interaction in the UI.
If any layer pretends the full dataset is “just local state”, the browser eventually pays for it.
Measure the shape of the problem
Before optimizing components, capture:
- transferred payload size;
- retained heap after repeated navigation;
- number of mounted rows and cells;
- request duplication;
- API query time.
This separates rendering cost from data-retention cost and backend cost.
The practical rule
Do not optimize the component before deciding whether the component should own the data at all.
For large operational datasets, server-side query semantics are often the highest-ROI frontend optimization.