Building a High-Performance React Scheduler with Virtualization

Every React timeline scheduler faces the same problem: as the number of events grows, the DOM grows too — and rendering thousands of absolutely positioned elements simultaneously kills scroll performance. The standard fix is virtualization (also called windowing). Here is how it works, why it is harder to apply to a 2D timeline than to a vertical list, and how Planby implements it to maintain 60fps with 10,000+ events.

Why naive rendering fails at scale

A React timeline scheduler maps events to absolutely positioned DOM elements inside a scrollable container. Each event needs a left, width, and top value calculated from the event's start time, duration, and resource row.

With 100 events this is trivial — 100 DOM nodes, each painted once. With 10,000 events the browser must:

The result: janky scrolling, high memory usage, and sometimes a completely unresponsive tab. This is not a React problem — it is a DOM problem. The browser simply cannot efficiently manage that many painted nodes.

Virtual rendering: only mount what is visible

The solution is to render only the events that intersect the current viewport. When the user scrolls, unmount events that have left the viewport and mount the newly visible ones. From the browser's perspective, there are never more than ~50 DOM nodes on screen — regardless of how many events exist in the dataset.

Libraries like react-window and react-virtualized implement this for simple vertical lists. A timeline scheduler, however, is a 2D surface — it scrolls both horizontally (time axis) and vertically (resource/row axis). Naive list virtualization only solves one axis.

DOM node count: virtualized vs non-virtualized

The clearest way to see the impact of virtualization is to compare DOM node counts at different dataset sizes. With a virtualized scheduler, the count stays constant because it only depends on how many events fit in the current viewport — not on total dataset size.

DOM node count with Planby is determined by viewport dimensions (how many events fit on screen), not by total dataset size.

How Planby implements bidirectional windowing

Planby's useEpg hook calculates three things on every scroll event:

The hook returns a filtered epg array containing only the events that should be rendered. The Layout component maps over this array and renders the visible events. When the user scrolls, React reconciles the diff — new events appear, out-of-view events disappear.

60fps scroll performance: the rendering budget

To maintain 60fps, each frame must complete in under 16.67ms. With 10,000 events mounted naively, a single scroll event triggers reflows across thousands of DOM nodes — easily exceeding that budget and producing visible jank.

With virtualization, a scroll event only needs to:

The total cost per scroll event stays well within the 16ms budget. Users see smooth, responsive scrolling regardless of how large the underlying dataset is.

Beyond events: virtualizing rows too

A scheduler with 500 resources (rows) has the same problem on the vertical axis. Planby handles this by also virtualizing the row (channel) list. Only the rows that are currently visible in the vertical viewport are rendered — the sidebar labels and the event rows together.

This matters for use cases like large employee shift schedulers, hotel room booking systems, or production line planners where there may be hundreds or thousands of resource rows.

Why most React schedulers do not virtualize

Bidirectional virtualization on a 2D time-axis is significantly more complex than a simple vertical list. Most React scheduler libraries skip it for this reason — FullCalendar, React Big Calendar, and DHTMLX Scheduler all render their full event datasets into the DOM. This works acceptably for small datasets (under a few hundred events) but degrades predictably as dataset size grows.

Summary

Virtualization is not optional for production-grade React timeline schedulers with real-world data volumes. The key points:

If you are evaluating React scheduler libraries for a data-heavy use case, virtual rendering is the single most important capability to check for. Without it, any library will hit a wall as your data grows.