Performance

Practical performance guidance for ZenGrid.

ZenGrid performance depends on data size, renderer cost, column count, overscan, device speed, and whether data is frontend or backend driven.

Start With A Measurable Grid

const grid = new Grid(document.getElementById('grid')!, {
  columns,
  rowCount: rows.length,
  colCount: columns.length,
  rowHeight: 36,
  colWidth: columns.map((column) => column.width ?? 140),
  overscanRows: 10,
  overscanCols: 5,
  enableCellPooling: true,
});

grid.setData(rows);
grid.render();

console.log(grid.getStats());

Renderer Cost

const statusRenderer = {
  render(element, { value }) {
    element.textContent = String(value);
    element.dataset.status = String(value).toLowerCase();
  },
  update(element, params) {
    this.render(element, params);
  },
  destroy(element) {
    element.textContent = '';
    delete element.dataset.status;
  },
};

Prefer simple DOM updates in renderers. Avoid layout reads, large nested DOM trees, and expensive formatting inside hot paths.

Overscan Tuning

grid.updateOptions({
  overscanRows: 8,
  overscanCols: 4,
});

Tune overscan with real data and target hardware. More overscan is not always faster.

Frontend vs Backend

• Use frontend mode with setData() when the full row matrix is comfortably held in memory.
• Use backend mode when data needs server-owned sorting, filtering, pagination, or windowing.
• Keep backend responses fast and cancellable with the provided AbortSignal.

Updating Cells

rows[10][2] = 'Updated';
grid.updateCells([{ row: 10, col: 2 }]);

grid.refresh();

Use updateCells() for targeted changes and refresh() for broader redraws.

Checklist

• Measure with grid.getStats() in the workflow you care about.
• Keep colCount and columns.length aligned.
• Keep renderers and editors cheap.
• Avoid expensive scroll handlers.
• Validate backend mode with production latency and realistic cancellation.
• Test on the slowest supported device, not only on a development machine.