Optimisation

Overview

Most DataTable performance problems come from the data flow around the table rather than from the renderer itself. The best results usually come from stable inputs, a clear decision about where filtering and searching happen, and virtualization once row counts grow.

Stable Inputs

• Keep columns stable with useMemo when they contain custom renderers or metadata.
• Avoid rebuilding large data arrays on every render unless the contents really changed.
• Provide getRowId whenever rows already have stable ids. This improves selection, editing, and virtualization behavior.

Choose Where Work Happens

• Use local search and client-side filters for small to medium datasets.
• Move search, filtering, and pagination server-side once network latency is cheaper than repeated browser work.
• Enable only the feature flags you need. Each extra row model adds work.

Keep Cell Renderers Cheap

• Prefer small, pure cell renderers over large components with their own expensive state.
• Use lightweight formatting and memoized lookup data instead of recomputing heavy values per cell.
• Keep inline edit opt-in and column-scoped rather than making every cell editable by default.

Use Virtualisation Deliberately

• Reach for virtualization when row counts are large enough that DOM size becomes the bottleneck.
• Set virtualRowHeight close to reality so the virtualizer does less correction work.
• Increase virtualOverscan only when scroll smoothness needs it. Higher overscan means more rendered rows.

Performance Knobs