Next.js 16.1 File System Caching: 10x Faster Dev Startup

Every time I restarted the dev server on our main application, I'd wait 12-15 seconds. Open laptop, run npm run dev, wait. Switch branches, restart, wait. After a crash, restart, wait. These waits accumulated into real lost time over a workday.

Next.js 16.1, released December 18, 2025, changes this. With Turbopack file system caching now stable and enabled by default, our dev server starts in under 2 seconds. The same 15-second startup now takes 1.1 seconds on average.

What File System Caching Does

Turbopack, the Rust-based bundler that became the default in Next.js 16, now persists its compiler state to disk between dev sessions. When you stop and restart next dev, Turbopack doesn't rebuild everything from scratch. It loads the cached module graph, resolved dependencies, and transformation results from disk.

The first run still takes normal time—Turbopack needs to analyze your codebase and build the initial cache. But every subsequent restart loads from cache, making startup nearly instant.

This is specifically for development. Production builds are unaffected. The cache only matters when you're iterating locally.

Performance Numbers

On our largest application (approximately 800 components, 200k lines of TypeScript), the difference is significant:

| Scenario | Before 16.1 | With 16.1 FS Cache | |----------|-------------|---------------------| | Cold start (first run) | 15.2s | 15.4s | | Warm restart | 15.2s | 1.1s | | Restart after editing 1 file | 15.2s | 0.8s | | Restart after branch switch | 15.2s | 2.3s |

The 13x improvement on warm restarts matches what Vercel reported for their internal applications. Branch switches are slightly slower because some cached modules may be invalidated, but still dramatically faster than full rebuilds.

How the Cache Works

Turbopack stores its cache in the .next/cache/turbopack-dev directory. The cache contains:

• Module graph: The dependency relationships between files
• Resolved imports: Where each import statement points
• Transformation results: Compiled TypeScript, JSX transformations, CSS processing

Files are stored with content hashes. When you edit a file, only that file and its dependents need reprocessing. The rest loads from cache.

The cache is automatically invalidated when:

• You edit a source file (only affected modules reprocess)
• You modify next.config.ts (full recache)
• You update dependencies in package.json (partial recache)
• Cache files become corrupted (automatic fallback to full rebuild)

Configuration

File system caching is enabled by default in Next.js 16.1 when using Turbopack. You don't need to configure anything—it works out of the box with next dev.

If you need to disable it (rare), use the experimental config:

// next.config.ts
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  experimental: {
    turbopackFileSystemCacheForDev: false,
  },
};
 
export default nextConfig;

Reasons to disable:

• Debugging cache-related issues
• Testing cold start performance
• Unusual filesystem configurations that cause cache corruption

For most projects, leave it enabled.

Cache Location and Size

The cache lives in your project's .next/cache directory:

.next/
├── cache/
│   └── turbopack-dev/
│       ├── module-graph.bin
│       ├── transforms/
│       └── ...

For our 800-component application, the cache is approximately 450MB. Large monorepos may see caches up to 1GB. The cache is automatically managed—old entries are pruned, and corruption triggers automatic rebuilds.

To manually clear the cache:

rm -rf .next/cache

This forces a full rebuild on next startup. Useful when troubleshooting or after major dependency changes.

Working with Branches

Branch switching is where caching gets interesting. When you switch branches:

1. Turbopack loads the existing cache
2. Files that changed between branches are detected
3. Only changed modules and their dependents are reprocessed
4. Unchanged modules load from cache

If branches have significantly different codebases (like switching from main to a major refactor branch), more modules need reprocessing, and startup takes longer. But it's still faster than a full rebuild.

For branches with minor differences, startup is nearly as fast as a normal warm restart.

Integration with Turbopack Features

File system caching is part of the broader Turbopack performance story in Next.js 16:

Fast Refresh: Already 5-10x faster than webpack, Fast Refresh benefits from cached module state. Edit a component, and only that component's subtree updates.

React Compiler: The React Compiler's build-time analysis is also cached. Memoization decisions don't need recomputation on restart.

Incremental Compilation: Changes to individual files process incrementally, building on the cached state rather than reprocessing the entire application.

CI/CD Considerations

File system caching is designed for local development. In CI pipelines, you typically want clean, reproducible builds:

# .github/workflows/ci.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
 
      - name: Install dependencies
        run: npm ci
 
      - name: Build
        run: npm run build  # Production build, cache doesn't apply

The Turbopack dev cache doesn't affect next build. Production builds run independently and don't use or populate the dev cache.

For local development in CI (like running integration tests against the dev server), the cache works normally but starts cold since CI environments are ephemeral.

Troubleshooting

Cache Seems Stale

If you're seeing outdated behavior after code changes:

rm -rf .next/cache && npm run dev

This forces a complete rebuild. If the issue persists, it's not cache-related.

Startup Still Slow

Verify you're using Turbopack:

# Should show Turbopack startup message
npm run dev

If you see webpack starting, check your npm scripts—some projects override the default to use webpack.

Large Cache Size

For very large projects, the cache can grow. Monitor with:

du -sh .next/cache

If it exceeds 2GB, something may be wrong. File an issue with the Next.js team.

Debugging Cache Behavior

Enable Turbopack debug logging:

NEXT_TURBOPACK_LOG=dev npm run dev

This shows cache hits, misses, and invalidations in the console.

Practical Impact

The real benefit isn't the benchmark numbers—it's the workflow change. I no longer hesitate to restart the dev server. Context switching between projects is faster. Morning startup is instant after yesterday's cache.

Small quality-of-life improvements compound. A 14-second savings on each restart, across dozens of restarts per day, adds up to meaningful time.

Combined with Turbopack's Fast Refresh improvements and React Compiler's automatic optimizations, Next.js 16.1 makes the development experience noticeably smoother.

For teams on large codebases where dev server startup was a pain point, the upgrade to 16.1 is worth it for file system caching alone.