What changed when we moved to Turbopack

The dashboard had two related problems: repeat builds interrupted the development loop, and several large browser libraries loaded before a visitor needed them. Moving to stable Turbopack and the TypeScript 7 native compiler gave us a chance to measure both. It did not produce one simple victory.

The first result changed the story

Our practical Webpack baseline completed in 21.9 seconds. A clean Turbopack build took 46.5 seconds, so the cold path regressed. The next Turbopack build completed in 8.32 seconds and used less aggregate Node working memory than the earlier baseline.

Those runs had different cache states. They answer a narrow question about this Windows checkout, not whether Turbopack is universally faster. The useful decision was to improve the repeated workflow without hiding the cold regression.

TypeScript 7 needs a compatibility seam

TypeScript 7.0.2 is a native compiler and does not expose the legacy JavaScript compiler API. The current Next.js configuration tooling and typescript-eslint still need that API. Pretending otherwise made lint fail immediately.

We use Microsoft’s side-by-side compatibility package: the explicit repository type-check runs TypeScript 7, while Next’s configuration and route-type setup plus ESLint consume the TypeScript 6 API. The production build is ordered so the TypeScript 7 check must pass before Next skips its duplicate TypeScript 6 build check.

experimental: { useTypeScriptCli: false },typescript: { ignoreBuildErrors: true }
// package script:// npm run type-check && next build

The analyzer mattered more than the bundler switch

The Turbopack analyzer showed that Recharts, Framer Motion, and Lenis were entering client graphs earlier than their value justified. The usage chart now loads independently from its controls and accessible data table. The below-fold proof animation waits until it nears the viewport. Smooth scrolling imports Lenis only on a fine-pointer desktop after reduced-motion checks pass.

We also turned the documentation frame back into a Server Component. Search, mobile navigation, theme persistence, active links, and the table of contents remain client islands, but the static reading frame and article content no longer share one broad hydration owner. The TOC indicator now uses a native CSS path transition, keeping Framer Motion out of the initial documentation graph.

The authentication boundary did not move

Dashboard layouts and pages previously repeated the same session and developer lookup during one server render. They now share React’s request-scoped cache. API handlers deliberately do not use it, and the cache still performs the normal server-side session-revocation check once per render request. Nothing persists across users.

This release does not claim a new hosted login SLO. Build speed, browser loading, database latency, proof generation, and network time remain separate measurements. A faster number is useful only when the system around it keeps the same security boundary.