Every grid library says it's fast. Proving it is harder, so I built a benchmark you can run yourself.
Show, Don't Tell
The benchmark lives on my documentation site as an interactive demo. Click a button, wait a few minutes, get numbers. No install, no setup, no trust required.
Both grids render into the same container, one at a time. Same column definitions (10 columns), same generated data, same operations. Scale points: 5K, 100K, 500K, and 1M rows. Nine metrics — initial render, scroll frame time, sort, filter, data replacement, single row update, column resize, scroll-to-end, and memory. Nothing exotic. These are the operations your users actually do.
Each metric runs 5 iterations per scale point. I drop the high and low, report the trimmed mean. This kills GC spikes and JIT warm-up noise that make single-run benchmarks useless. Timing uses performance.now() around the API call plus one requestAnimationFrame to capture deferred rendering. Both grids measured the same way. AG Grid Community loaded from CDN, latest version. No enterprise features on either side.
The Numbers
Here's a typical run:
| Metric | Toolbox Grid advantage |
|---|---|
| Initial render | 2.5× faster |
| Scroll avg frame | 1.4× faster |
| Sort | 13.1× faster |
| Filter | 1.5× faster |
| Data replacement | 1.8× faster |
| Single row update | 2.7× faster |
| Column resize | 2.3× faster |
| Scroll to end | 1.5× faster |
Toolbox Grid won 30 of 36 data points across all scale points and metrics. One tie. Geometric mean across all time-based metrics: 2.3× faster.
That Sort Number
Yeah, 13.1×. At 1M rows: ~19ms vs ~292ms. I double-checked this one multiple times because it looked wrong. It's not. The grid sorts in-place with a compiled comparator — no intermediate array allocation, no copying a million elements into a new structure. The difference compounds at scale.
Where AG Grid Wins
Memory at 1M rows. At smaller datasets (5K–500K), Toolbox Grid uses less heap. But at a million rows, AG Grid's memory footprint is about 1.2× smaller. This is real, I'm not going to hide it, and it's something I'm actively working on.
The Small Dataset Reality
At 5K rows, most of these metrics land under 17ms — one frame at 60fps. Both grids handle it fine. Performance alone won't decide anything at that scale.
But here's what might: Toolbox Grid's core is ~42KB gzipped. AG Grid Community is ~200KB+. You're getting a grid that's both faster and a fifth of the size. For teams that care about Core Web Vitals, mobile load times, or just not shipping 200KB of JavaScript for a table — that math is hard to ignore, even before the performance gap kicks in at 100K+ rows.
Why It's Fast
~42KB gzipped, zero dependencies, no framework runtime. Toolbox Grid is a native Web Component. No virtual DOM diffing, no reconciliation loop. Less to parse, less to evaluate, faster time-to-interactive. When the grid decides to update a cell, it updates a cell.
Virtualization with DOM recycling. Only visible rows exist in the DOM — but I don't destroy and recreate them on scroll either. The same row elements stay in place; only the data inside them changes. DOM operations are expensive. Moving text content between existing elements is almost free. That's why scroll frame times stay flat from 5K to 1M rows.
In-place sort. Most grids allocate a new array, copy the data, then sort the copy. At a million rows, that allocation and copy is the real cost — it dwarfs the time spent in the actual sort loop. Toolbox Grid sorts its internal array in-place with a pre-compiled comparator, skipping the allocation entirely.
Compiled filter predicates. A numeric filter compiles to row.id > threshold, not a generic function that coerces types on every row. At 500K+ rows, that per-row overhead is measurable.
Phase-based render scheduler. Updates don't just batch into a single requestAnimationFrame — they flow through a six-phase pipeline where higher phases implicitly cover lower ones, so no work runs twice. Scroll rendering bypasses the scheduler entirely as a synchronous hot path. The full details are in the architecture docs.
It's Not Just Performance
Performance matters, but not if the grid can't do what you need. Toolbox Grid covers the same ground as AG Grid Enterprise — range selection, clipboard, row grouping, pivot tables, tree data, master-detail, server-side data, context menus, Excel export, undo/redo, column groups, drag & drop, print — all under MIT. The full plugin list is worth a look if you're comparing feature sets.
The framework adapters aren't thin wrappers either. Angular gets structural directives (*tbwRenderer, *tbwEditor), reactive forms integration, and injectable services like injectGridSelection(). React gets JSX renderers, onRowsChange callbacks, and feature-scoped hooks like useGridFiltering(). Vue gets #cell/#editor slots and composables. Each adapter speaks its framework's language — you're not writing Web Component boilerplate in an Angular app.
Run It Yourself
The benchmark is client-side and deterministic. Visit the comparison page, click Run Comparison, and watch it work through 5K → 100K → 500K → 1M rows. Takes a few minutes.
The source is on GitHub. No hidden test harnesses.
If you find a scenario where AG Grid is faster — beyond memory at 1M — open an issue. I'll either fix the grid or add the scenario to the benchmark.
The numbers are there. Run them.
Tested: Toolbox Grid (latest) vs AG Grid Community (latest, CDN). Chrome, Windows 11. Relative performance is what matters — absolute ms varies by hardware.