# Virtualisation saves rendering work, not database work

Separate the cost of fetching, sorting and displaying records. Choose pagination or virtualisation for the stage that actually limits the task.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Measure the expensive boundary

A table can be slow because the server scans too much data, the response is large or the browser renders many complex cells. Measure those stages separately before replacing the component.

Virtualisation reduces the rendered subset but does not automatically reduce downloaded data or server query cost. Loading 100,000 records to display 30 visible rows can still be expensive on a phone connection.

Use realistic cell content, including menus, status labels and long text. A benchmark of plain numbers may understate the layout and interaction cost of the actual application.

## Choose a data window that fits the task

Server pagination can bound payloads and make query cost manageable. Cursor-based navigation may suit changing datasets, while a stable page model may better match other workflows. Define ordering and tie-breaking so records do not unpredictably repeat or disappear between requests.

Do not claim that a displayed count is exact if the backend provides only an estimate. Counts and totals can require separate work from fetching one page.

For comparison tasks, users may need a focused export or report rather than an endless interactive list. That path should preserve authorisation and explain its scope.

## Account for virtualisation's interaction cost

A virtualised view must handle focus and assistive-technology context when rows enter and leave the rendered window. Test the selected library's behaviour with the intended navigation model.

Variable row heights and expanded details can complicate scroll position. If opening a row causes the list to jump, the performance optimisation has damaged the task.

Use virtualisation when measured scale warrants that complexity. A modest paginated table may be easier to operate and maintain while meeting the required latency.

## Budget for complete interactions

Include sorting, filtering, selection and return-from-detail in performance testing. A fast initial paint followed by long stalls on every filter change is not a responsive table.

Cache appropriate query results under the correct account and invalidation rules. Avoid displaying stale eligibility as current authority for an action.

The final decision should identify the bottleneck and the evidence that the chosen approach improves it. Rendering fewer rows is valuable when rendering is the problem, not as a substitute for understanding the data path.

## Sources

- [W3C APG: grid pattern](https://www.w3.org/WAI/ARIA/apg/patterns/grid/)