TanStack Table V9 Beta: tree-shaking the grid so INP stops paying for unused features

The support ticket is rarely “the homepage is slow.” More often it says the orders table freezes when someone filters. Marketing pages can look fine in the Chrome UX Report while the signed-in grid that matters still feels sticky on every sort click, and Interaction to Next Paint is where that lag shows up. TanStack Table V9 beta is aimed at those screens: tables that piled on sorting, filtering, pagination, and selection under V8, then shipped all of that code even when the page used only a slice of it. Lead maintainer Kevin Van Cott’s TanStack Table V9 announcement (8 June 2026) and InfoQ’s beta write-up centre on opt-in features and state built on TanStack Store. For agencies and product teams, the better question is not “should we rewrite every grid this sprint?” It is which money URLs still download table code nobody clicks, and how you will prove INP improved after you trim them.

What was wrong with TanStack Table V8 for large grids

V8 worked well for years, but the costs show up on large, virtualised lists. Its state patterns did not match what the React Compiler expects, so V8 started breaking once the compiler became stable. Updates were blunt: selecting a row could redraw filter bars and pagination that never showed selection. Virtualised tables still built more row and cell objects than the visible window needed. Simple lists felt overweight, while deep custom behaviour felt underserved, because most features arrived in one package. You could wrap tables for reuse, but the docs never made that path obvious, and the developer tools stayed thin.

Those points come from the V9 maintainers, not from agency guesswork. If the “data grid” page is the one account managers apologise for in quarterly reviews, you have already seen the symptoms even if nobody named TanStack. The state and feature rewrite targets that lag, not marketing homepage scores.

How V9 tree-shaking changes what the browser downloads

In V9, you turn features on the way you add plugins. You compose tableFeatures({ rowPaginationFeature, rowSortingFeature, ... }) with the matching row models. Skip sorting and you do not download sorting code, and TypeScript will not offer setSorting until that feature is registered. InfoQ cites a small table near 5kb, while a full grid only pulls in the features it needs. stockFeatures brings back the V8 “include everything” setup while you migrate, but you give up most of the size saving. You still write the HTML yourself; TanStack stays headless.

That is the performance story in plain terms: stop paying main-thread and parse cost for grid features the route never uses. It is the same discipline we already apply to third-party tags. Unused chat widgets and unused column-pinning code both compete for the thread that serves clicks. For the tag side of that ledger, see Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders. Treat first-party table features with the same inventory habit: list what each money URL actually enables, then delete or defer the rest.

How TanStack Store and Subscribe affect INP on table pages

V9 builds state on TanStack Store. You can still hoist pagination the V8 way. You can also bind atoms and subscribe narrowly. table.Subscribe lets a selected-row count re-render from rowSelection without refreshing filter chrome, pagination, and every cell wrapper that merely holds the table instance. Fine-grained subscriptions matter when INP is measured on the interaction that starts a filter or toggles a checkbox across thousands of rows. Less work between input and next paint is the entire point of the metric.

INP became a Core Web Vital because page load paint was never enough to describe responsiveness after the first screen. We explain thresholds and why agencies still miss click latency in Understanding INP: The Newest Core Web Vital and Why It Matters. A V9 migration that only shrinks the marketing bundle while leaving the orders grid on V8 with stockFeatures will not move the tickets that mention frozen filters.

Memory work in V9 also targets virtualised tables: shared prototypes, fewer per-row method allocations, fewer intermediate arrays. That helps long sessions on dense authenticated URLs where garbage collection pauses show up as jank between clicks. Bundle size and allocation rate are different levers; V9 pulls both.

How to migrate a client grid without a big-bang rewrite

Van Cott ships a gradual path: useLegacyTable accepts V8-shaped APIs on V9, and stockFeatures buys time. Use that bridge for production stability, not as the forever default for new screens. A practical sequence for an agency or SaaS team:

Inventory authenticated money URLs that host heavy tables (orders, inventory, reporting, CRM lists).
Capture INP (lab interaction traces and field where available) plus long tasks on those URLs before changing libraries.
Migrate one grid with only the features that screen uses; leave stockFeatures off the new code path.
Re-measure the same interactions (sort, filter, select, paginate).
Schedule those URLs so the next feature flag or tag manager change cannot erase the win unnoticed.

Do not sell V9 beta as a drop-in for every framework adapter overnight. Angular and React teams have already flagged that atoms are not identical to old controlled-state habits. Pilot one grid, document the feature list, then decide whether the rest of the portfolio upgrades this quarter or next.

What V9 does not fix on a slow application URL

Tree-shaking will not rescue an unbounded JSON payload, a synchronous chart library beside the table, or a third-party session replay script that hooks every pointer event. It will not fix CLS from late-loaded column widths. It will not replace a monitoring schedule with a single Lighthouse run on /. Layer the library upgrade onto budgets you already keep for scripts and images. Keep Watcher or PageSpeed schedules on the authenticated templates you can reach in lab, and keep RUM on the interactions users actually perform.

On Monday, open the worst table URL in your portfolio. List every TanStack feature (or equivalent grid feature) that page enables. Mark which ones the UI never exposes. That list is your V9 migration brief. Pair it with an INP baseline and a third-party script inventory so you are not chasing a 5kb win while a tag still owns the main thread.