English for Turbopack
Learn the English vocabulary for Turbopack, Next.js's Rust-based bundler: incremental computation, the turbo engine, and cache invalidation.
Turbopack’s pitch is speed through incremental, function-level caching rather than just “it’s written in Rust so it’s fast,” and explaining the actual mechanism requires vocabulary that goes beyond that shorthand. This guide covers the terms.
Key Vocabulary
Incremental computation — Turbopack’s core architecture, where the bundler tracks fine-grained dependencies between build steps so that changing one file only recomputes the specific outputs that depend on it, not the whole graph. “The rebuild was instant because incremental computation only reprocessed the one component you changed, not the entire page’s dependency tree.”
Function-level caching — the practice of memoizing individual build operations (like transforming a single file) so identical inputs never get recomputed, even across different build steps that happen to need the same result. “Two different parts of the build needed the transformed version of that file, and function-level caching meant it was only computed once, not twice.”
Turbo engine — the underlying incremental computation engine that Turbopack (and Turborepo) is built on, responsible for tracking task dependencies and invalidating only what’s actually affected by a change. “Both Turbopack and Turborepo share the same turbo engine under the hood — that’s why the caching behavior feels conceptually similar across the two tools.”
Cache invalidation (graph-aware) — Turbopack’s approach of invalidating only the specific cached computations affected by a file change, based on the dependency graph, rather than a coarser cache-busting strategy. “The stale output you’re seeing suggests a cache invalidation bug — some dependency edge isn’t being tracked, so a change isn’t propagating to everything that should be recomputed.”
Development server compile time — the metric most commonly cited when comparing Turbopack to Webpack, referring to how quickly the dev server reflects a saved change in the browser. “Compile time on save dropped from a couple of seconds to under 200 milliseconds after switching the dev server to Turbopack.”
Persistent caching — Turbopack’s ability to reuse cached computation results across separate dev server sessions (e.g., after restarting), rather than starting from a cold cache every time.
“Persistent caching is why the second next dev startup this morning was much faster than the first — it reused yesterday’s cached build artifacts.”
Common Phrases
- “Is this rebuild slow because of a real code change, or is incremental computation not kicking in for some reason?”
- “Are we seeing stale output because of a cache invalidation bug, or did the change genuinely not affect this file?”
- “What’s the compile-on-save time looking like since the Turbopack switch — is it actually faster in practice?”
- “Is this using persistent caching, or are we starting from a cold cache every session?”
- “Is this specific to Turbopack, or is it a turbo engine issue that would also affect Turborepo?”
Example Sentences
Explaining a migration decision: “We switched the dev server to Turbopack mainly for the incremental computation model — large page changes used to trigger a much broader rebuild under Webpack than the actual change warranted.”
Reporting a cache bug: “We’re seeing an old version of a shared component render after editing it, which points to a cache invalidation issue — some dependency edge between that component and the page isn’t being tracked correctly.”
Discussing build performance with a teammate: “The compile time improvement is most noticeable on large pages with deep component trees — that’s exactly where incremental computation has the most stale work to avoid recomputing.”
Professional Tips
- Explain speed gains via incremental computation, not just “it’s Rust” — the architecture, not the language, is what actually produces the improvement.
- Reference cache invalidation explicitly when reporting stale output — it points a reviewer directly at dependency-tracking logic rather than a vague “the build is broken.”
- Use compile-on-save time as the concrete, measurable metric when comparing bundler performance — it’s more useful in a discussion than a general “it feels faster.”
- Mention persistent caching when discussing cold-start versus warm-start dev server performance — conflating the two produces misleading benchmark comparisons.
Practice Exercise
- Explain incremental computation to a teammate in two sentences.
- Write a bug report describing stale output likely caused by a cache invalidation issue.
- Describe, in your own words, the difference between a cold start and a warm start with persistent caching.