Rendering 100k Rows: How Far Can the DOM Go? (Part 1: Pagination) // MANOJ MOHAN

Welcome to Part 1 of our series, "Rendering 100k Rows: How Far Can the DOM Go?"

When building dashboards, databases, or analytics platforms, you will eventually face the dreaded requirement: "We need to display a massive table of data."

If you attempt to render 100,000 rows directly into the DOM using a standard HTML table, your browser tab will freeze, your CPU fans will spin up, and the page will eventually crash. But why?

Before we look at virtualization or drawing pixels on a Canvas, let's look at the classic, battle-tested solution: Pagination.

The Physics of the DOM: Why 100k Rows Crash the Browser

To understand why pagination is so effective, we must understand the cost of a DOM node.

In a standard browser, an HTML element isn't just text. It is a complex JavaScript object with styling computations, layout boundaries, event listeners, and accessibility roles.

A simple table row (<tr>) with 5 columns (<td>) contains at least 6 DOM nodes.
Rendering 100,000 rows means mounting 600,000 DOM nodes!

When you insert 600,000 nodes, the browser’s layout engine goes through a multi-step process:

Recalculate Style: Determine the CSS rules for all 600k nodes.
Layout (Reflow): Calculate the exact position and size of each element.
Paint: Rasterize the pixels onto the screen.

If the user scrolls, resizes the window, or hovers over a row, the browser might trigger another reflow. Doing this for over half a million elements at 60 frames per second is mathematically impossible for modern CPU threads.

Enter Pagination: Capping the DOM

The core philosophy of pagination is simple: Do not render what the user cannot see.

Instead of loading all 100,000 records onto the screen, pagination partitions the dataset into small chunks (usually 10, 25, or 100 items at a time).

[ Page 1 (Items 1-10) ]  --> Rendered in DOM (Fast!)
[ Page 2 (Items 11-20) ] --> In Memory / Database (Not Rendered)
[ Page 3 (Items 21-30) ] --> In Memory / Database (Not Rendered)

By capping the rendered elements to 10 or 100 rows, the active DOM nodes stay under 600. The browser style recalculation takes microseconds, and interactions remain fluid.

Visualizing the Pagination Pipeline

Here is an interactive diagram showing how the data is loaded on demand. Click Next Page or Prev Page to see how the indicator slides down your dataset array, triggering a load pulse into the active browser DOM.

Interactive Flow Diagram

Page 1 / 10000

Client-Side vs. Server-Side Pagination

When implementing pagination, you have two routing architectural paths:

1. Client-Side Pagination

You fetch all 100,000 rows from the server in a single JSON payload, store them in JavaScript memory (an array), and slice the array in the frontend to render the current page.

Pros: Page transitions are instant because the data is already in memory.
Cons: The initial page load is slow because the browser has to download and parse a massive JSON payload (often 10MB+). High memory usage.

2. Server-Side Pagination

The frontend only requests the current page slice from the server (e.g., GET /api/users?page=1&limit=10). The database uses query offsets (LIMIT 10 OFFSET 0) to fetch only those 10 rows.

Pros: Tiny network payloads, instant initial load, and minimal frontend memory footprint.
Cons: A slight delay (network roundtrip) every time the user clicks "Next Page".

Interactive Demo: Pagination in Action

Below is an interactive playground where we simulate a dataset of 100,000 records. Play with the page navigation and watch how quickly the rendering handles page switches.

Notice how the DOM tree size remains tiny, allowing the page to render instantly.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <style>
    body {
      font-family: system-ui, -apple-system, sans-serif;
      background: #0f172a;
      color: #f1f5f9;
      padding: 1.5rem;
      margin: 0;
    }
    .controls {
      display: flex;
      justify-content: space-between;
      align-items: center;
      margin-bottom: 1rem;
      background: #1e293b;
      padding: 0.75rem 1rem;
      border-radius: 8px;
    }
    .stats {
      font-size: 0.85rem;
      color: #94a3b8;
    }
    .btn {
      background: #3b82f6;
      border: none;
      color: white;
      padding: 6px 12px;
      border-radius: 4px;
      cursor: pointer;
      font-weight: 600;
      font-size: 0.85rem;
    }
    .btn:disabled {
      background: #475569;
      cursor: not-allowed;
      opacity: 0.5;
    }
    table {
      width: 100%;
      border-collapse: collapse;
      background: #1e293b;
      border-radius: 8px;
      overflow: hidden;
    }
    th, td {
      text-align: left;
      padding: 10px 12px;
      font-size: 0.9rem;
      border-bottom: 1px solid #334155;
    }
    th {
      background: #0f172a;
      color: #3b82f6;
      font-weight: 600;
    }
    tr:last-child td {
      border-bottom: none;
    }
  </style>
</head>
<body>

<table id="data-table">
    <thead>
      <tr>
        <th>ID</th>
        <th>Name</th>
        <th>Email</th>
        <th>Role</th>
      </tr>
    </thead>
    <tbody id="table-body">
      
    </tbody>
  </table>

// Lazy array generation to keep iframe load fast
    function getRecord(index) {
      return {
        id: index + 1,
        name: `User ${index + 1}`,
        email: `user${index + 1}@example.com`,
        role: index % 3 === 0 ? 'Admin' : (index % 2 === 0 ? 'Editor' : 'Viewer')
      };
    }

const tbody = document.getElementById('table-body');
    const prevBtn = document.getElementById('prev-btn');
    const nextBtn = document.getElementById('next-btn');
    const indicator = document.getElementById('page-indicator');

function renderPage() {
      const startIdx = (currentPage - 1) * pageSize;
      const endIdx = startIdx + pageSize;

tbody.innerHTML = html;
      indicator.textContent = `Page ${currentPage} of ${totalRecords / pageSize} (${startIdx + 1} - ${endIdx} of ${totalRecords.toLocaleString()} rows)`;

prevBtn.disabled = currentPage === 1;
      nextBtn.disabled = currentPage === (totalRecords / pageSize);
    }

prevBtn.addEventListener('click', () => {
      if (currentPage > 1) {
        currentPage--;
        renderPage();
      }
    });

nextBtn.addEventListener('click', () => {
      if (currentPage < (totalRecords / pageSize)) {
        currentPage++;
        renderPage();
      }
    });

// Initial render
    renderPage();
  </script>
</body>
</html>

The Verdict: When to use Pagination

While pagination solves rendering issues completely, it is a compromise.

Pros:

Unbeatable rendering speed: Your DOM stays clean and light.
SEO & Navigation: Standard URL queries (e.g., ?page=3) can be indexed by search engines and bookmarked by users.
Accessibility: Standard HTML links and tables are perfectly understood by screen readers.

Cons:

Broken User Flow: Users hate clicking "Next" repeatedly to find a specific row.
Inability to Compare: You cannot easily select elements on page 1 and compare them with elements on page 5.

If your users need an uninterrupted infinite scroll feed or need to work with huge grids seamlessly, pagination is not the answer.

In Part 2, we’ll explore how to build the illusion of infinite scrolling without overloading the browser using DOM Virtualization. Stay tuned!