A faster warm build, a slower cold one

Toolchain upgrades are easy to announce and surprisingly hard to describe honestly. We moved the ZKAuth dashboard to the stable Turbopack path in Next.js 16.3 and adopted the TypeScript 7 native compiler. Then we measured the result before deciding what counted as an improvement.

The result was not one clean win

The pre-migration Webpack build completed in 21.9 seconds: 7.5 seconds compiling and 2.1 seconds type-checking. Approximate peak aggregate Node working set was 3,212 MiB. That run had access to the checkout’s existing build state, so it is a practical local baseline, not a laboratory benchmark.

After moving the old build output aside, a cold Turbopack build took 46.5 seconds, including 34.3 seconds compiling and 968 ms type-checking. Peak aggregate Node working set was about 3,256 MiB.The cold path regressed, and changing the bundler did not make that fact disappear.

A subsequent warm Turbopack build completed in 8.32 seconds, with 2.8 seconds compiling, 356 ms type-checking, and roughly 2,745 MiB peak aggregate Node working set. Against the earlier practical Webpack run, that is about 62% less elapsed time and 14.5% less peak working set. Cache state differs between these runs, so the exact values are evidence for our workflow—not a universal Next.js comparison.

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 changed application code

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.

Faster rendering cannot weaken authentication

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 are different measurements. We will keep publishing them separately because a fast number is useful only when its boundary is clear.