Why Ant Design’s Table Is So Slow: Caching, Virtualization & Breaking Changes

Every few months a new Table component library appears on the market, and we keep comparing it with Ant Design's Table. Yet, no matter how many libraries evolve, React still lacks a Table that satisfies everyone. Today we discuss why Ant Design's Table feels so “slow”. Some reasons are historical, others are unavoidable.

Heavy caching in Ant Design Table

In the early v4 we refactored Table. The alpha Table caches all row and column data using memo, so as long as data does not change, the Table will not re‑render. This matches most expectations, but certain cases break this intuition.

const [count, setCount] = React.useState(0);

const columns = [
  { render: () => count },
];

return <Table columns={columns} {...} />;

In real business code, a Table cell is often not pure. Developers may use render to display additional state, such as the external count. Although data stays the same, the Table still needs to re‑render when count changes.

Another example uses a global variable:

let globalValue = 0;

const columns = [{
  render: () => globalValue,
}];

export default () => <Table columns={columns} />;

Even though columns does not change, the render function can still be affected by external state. Some developers try to add a deps array similar to useEffect, but business logic is often too varied to capture all dependencies, leading to missed updates and hard‑to‑detect bugs.

Everything can be virtualized, right?

Unlike other components, Table does not provide built‑in virtual scrolling. Virtual scrolling renders only the visible rows to save DOM nodes, but for editable tables this creates a problem: rows that are not rendered have no form fields, so the Form cannot collect their values. Ant Design's Form can collect unmounted fields with getFieldsValue(true), but that also brings unwanted data.

Components like Tree or Select mainly display data, so virtual scrolling does not interfere with side effects. Table, being highly flexible, often requires developers to implement custom logic for editable cells, which can be error‑prone.

Additional virtual‑scroll issues include unknown cell widths before rendering, sudden jumps during scroll, loss of auto‑width when fixing column width, and accessibility problems for cells that span rows.

Everything can break, right?

Maintaining a large component library inevitably introduces breaking changes. For example, Ant Design once had a misspelled API feildNames, which was kept for an entire major version before being corrected to fieldNames.

Table offers many “holes” for customization, such as the render method that can return node props, and the newer onCell method. Although both achieve similar outcomes, they behave differently: render returns props that cause child nodes to render, while onCell supplies props without triggering a child render, enabling better performance optimizations.

const columns = [{
  render: () => ({
    children: 'Hello World',
    rowSpan: 2,
    colSpan: 2,
  })
}];

Using onCell:

const columns = [{
  render: () => 'Hello World',
  onCell: () => ({
    rowSpan: 2,
    colSpan: 2,
  })
}];

In the latest version, examples have been switched to the onCell approach, and developers are warned that the render ‑return‑props pattern will be deprecated in the next major release.

Other performance pitfalls in Table include unnecessary re‑renders caused by context changes, resizable columns, and other bugs that are fixed as they are discovered.

Ultimately, optimizing a single issue is easy, but as business scenarios grow, a component library must balance performance with stability. Ant Design chose to expose shouldCellUpdate instead of automatically memoizing every cell, acknowledging that there is no silver bullet.