Performance benchmarks

Headline numbers from the regression suite. Every figure below is from the same hardware + browser configuration, re-measured on each release; the script that produces them lives in packages/sv-grid-community/scripts/bench.ts and is checked in.

Live load - 100k rows x 100 columns with row + column virtualization:

Test rig

Numbers are the median of 5 runs after a warm-up pass. We track the 95th percentile of frame time during scroll rather than mean FPS - the former catches jank that mean averages smooths over.

Bundle size

Production build, gzipped, measured on the dist/ output:

Tree-shaking is friendly: importing { SvGrid, tableFeatures } without rowSortingFeature doesn't pull the sort module.

First paint

100k synthetic rows, 9 columns, default density, no virtualization override. Measured from mount() to the first row painting:

The slope is sub-linear because virtualization caps the rendered cell count regardless of dataset size.

Scroll performance

Sustained vertical scroll, 60 px/frame, measured as the 95th percentile frame time:

Horizontal scroll on a 100-column grid stays under 12 ms p95 because the column virtualizer is identical machinery.

Sort, filter, group

In-memory operations on 100k rows:

The sort path uses a stable comparator built per-column to keep allocations down; the filter pipeline short-circuits on the first failing predicate.

Memory

Heap snapshot at idle, 100k rows × 9 columns loaded, after a full scroll pass:

• ~22 MB heap (the Row objects + the visible-cell pool).
• Virtualization keeps the rendered DOM under ~600 <td> nodes regardless of dataset size.
• No retained references when the grid unmounts - the cleanup path is exercised by the unmount test in svgrid.behavior.test.ts.

Server-side / chunked loading

Demo 33. Server-side infinite scroll covers the chunked-load path. Numbers from that demo:

AI helpers

End-to-end timings against the bundled mockAIProvider:

Against a real model the latency is provider-side. The grid's own prompt-build + result-parse work stays under ~6 ms even for 1000-row classify jobs.

Import / export

Reproducing locally

git clone https://github.com/sv-grid/sv-grid
cd sv-grid
pnpm install
pnpm bench       # runs the suite, prints the same table
pnpm bench --json > my-results.json  # for trend tracking

The bench script also produces a comparison table against the previous run if you pass --baseline=path/to/prev.json. Regressions over 10% fail CI on the main branch.

What we don't claim

• "Smoothest grid on the market" - that depends entirely on what your cells render. A sparkline + currency formatter in every cell costs more than a number, and we don't pretend otherwise.
• "Zero allocations during scroll" - the virtualizer recycles DOM nodes but cell snippets still allocate. The numbers above include real-world snippets (status pills, mini-bars).
• Single-thread performance > 1M rows. For >1M, do the heavy lifting on the server and feed chunks through the server-side infinite scroll pattern.

See also

• Browser support - the matrix the benchmarks ran against.
• Testing and quality - the coverage thresholds that gate every release.

Frequently asked questions

How fast is SvGrid?

It virtualizes both rows and columns, so only the visible window is in the DOM - a 100,000-row × 100-column grid scrolls smoothly. The numbers on this page come from a checked-in regression suite re-measured on every release, not marketing estimates.

How many rows can SvGrid handle?

Client-side, 100k+ rows scroll smoothly thanks to virtualization. For millions of rows, page or chunk from the server (see Server-side data). The DOM only ever holds the visible window regardless of total row count.

Is SvGrid faster than AG Grid or TanStack Table?

It ships a much smaller bundle (~42 KB gzipped for the full render component, or ~7.5 KB for the headless core) and virtualizes by default. Raw scroll performance is comparable for typical workloads; the bigger practical win is bundle size and a Svelte-native runtime with no framework bridge.