Caching is, of course, the intermediate storage of data to improve loading times and speed up performance. Persistent caching is something that is very common in database-driven projects, where the data pulled from the database is cached so the user has a copy of earlier versions. This can then be loaded all at once without causing too much demand from the database as data will be delivered at a slower rate than server-based file entries.

With Webpack 5, an application can utilize the same operation and improve the speed of loading for the user if the build changes.

First, note that persistent caching is not enabled by default. You have to opt in to using it. This is because Webpack 5 favors safety over performance. It is probably not the best idea to enable features that improve performance by even a small amount but break your code in any small way. At least as a default, this feature should remain disabled.

Serialization and deserialization would work by default; however, the developer may have trouble with cache invalidation.

Cache invalidation is when something changes in your application intentionally, such as when the developer changes the contents of a file; in this case, Webpack would regard the caching of the old content as invalid.

Webpack 5 does this by tracking fileDependencies, contextDependencies, and missingDependencies for each module used. Webpack then creates a filesystem schematic from this. The filesystem is then cross-referenced against the recorded copy and this, in turn, triggers a rebuild of that module.

The cache entry of the output bundle then has a tag generated for it; this is essentially a hash of all contributors. A match between the tag and the cache entry indicates content that can be used by Webpack for bundling.

Webpack 4 used this same process for in-memory caching and it will work in Webpack 5 without extra configuration unless persistent caching is enabled.

You also need to invalidate cache entries when you upgrade a loader or plugin with npm, change a configuration, or change a file that is to be read in the configuration, or when upgrading a dependency that is used in the configuration, when passing difference command-line arguments to run a build, or when you have a custom build script and make changes to it.

As Webpack 5 cannot handle these exceptions out of the box, persistent caching is made an opt-in feature for safety in regards to securing the integrity of your application.