Keep DataTables Fast With serverSide Processing For Large Datasets

Rendering tens of thousands of rows client-side makes DataTables slow and memory heavy. The practical decision is to enable serverSide processing so paging, sorting and filtering run on the backend and the browser only renders the current page.

When serverSide is the right call

With client-side DataTables the entire data set is loaded into memory and the DOM is built for all rows. Beyond a few thousand rows this causes long initial loads, janky scrolling and high memory use.

Setting serverSide: true keeps client memory and DOM node count constant. DataTables sends paging, ordering and search parameters to an endpoint, receives only the rows for the current page, and redraws from that payload. Total rows can grow without changing the client cost.

How the request/response contract works

Initialization is a single object. DataTables then manages the round trips.

$('#orders').DataTable({
  serverSide: true,
  processing: true,
  ajax: '/api/orders',
  pageLength: 25,
  columns: [
    { data: 'id', title: 'ID' },
    { data: 'customer', title: 'Customer' },
    { data: 'total', title: 'Total' },
    { data: 'created_at', title: 'Created' }
  ]
});

On page change, sort or search, DataTables issues a request with parameters such as draw, start, length, search[value] and order[0][column] / order[0][dir]. The backend must use those to build a paginated, sorted, filtered query.

The response must echo the request and provide counts.

{
  "draw": 3,
  "recordsTotal": 124832,
  "recordsFiltered": 8421,
  "data": [
    { "id": 10234, "customer": "Acme", "total": 1299.00, "created_at": "2026-01-12" }
  ]
}

draw must be returned unchanged to prevent out-of-order responses from being applied. recordsTotal is the total rows in the table without filtering. recordsFiltered is the total after applying the global search. data contains only the rows for the current page, matching length.

Limits to plan for

Each interaction requires a network round trip. Perceived latency rises compared with instant client-side filtering. The backend must implement stable sorting, correct pagination offsets and a global search that matches the UI expectation.

Client-side features that rely on the full data set are no longer available. Instant row grouping, local state filters and full-table search highlighting must be reimplemented server-side if needed.

Column renderers still run client-side, but only for visible rows. Heavy renderers are fine because they operate on pageLength rows, not the whole set.

Do not enable serverSide on small static tables. The extra requests add latency with no benefit when the full set fits comfortably in memory.

Common mistakes

Mixed modes. Options like searchDelay, local filter callbacks or deferRender tuned for client data do not apply when serverSide is true. Keep the configuration server-centric.

Mismatched draw echo. Returning a different draw value or omitting it causes DataTables to discard the response.

Confusing recordsTotal and recordsFiltered. Setting both to the same value hides the effect of filtering in the UI footer.

Sending all rows. Returning the entire data set with serverSide enabled defeats the purpose and can hang the UI. The data array should match the requested page size.

Version sensitivity. Parameter names for ordering and search are stable in modern builds but older builds differ. Verify the request shape in devtools for the version in use.

Check it works

Open browser devtools network tab and change page or sort a column. Verify a request is made to the configured ajax endpoint with query parameters draw, start, length, order and search.

Inspect the response JSON for draw, recordsTotal, recordsFiltered and a data array whose length matches length. Changing page should change start and the returned rows without growing DOM nodes.

Count tr elements in the table tbody after load. It should stay close to pageLength regardless of the total rows reported.