What is Better: Preloading or Caching JavaScript Modules?

Better for both users and developers.

Bundling is good for users but it causes a nightmare for developers. It is particularly annoying to depend on bundlers during development. Unfortunately, bundling is not always optional. For example, the developers who have to transpile are doomed to bundle.

Preloading and caching of modules are the two principal techniques relieving developers of bundlers that are used for no valid reason.

I described previously the rationale and the striking effect of module preloading.

Caching modules is even more effective, however, it should be done properly so that the cached modules can be easily updated when a new version of the web application is released.

What happens if modules are both preloaded and cached in the automatically refreshing up-to-date cache?

For this experiment, I adapted the sample web page that is described in the previous post about preloading.

Briefly, during the benchmarking, I measure the loading time of a module dependency tree composed of 255 modules. The experimental tree is a perfect binary tree with 8 levels containing 1, 2, 4, 8, 16, 32, 64, and 128 modules respectively. Before the browser comes to know about any of the leaf modules, it has made 7 sequential requests to load its 7 parents. The tree is purely experimental rather than real-life.

The loading time of the entire module tree is measured in four different settings:

• the modules are not preloaded and not cached
• the modules are preloaded but not cached
• the modules are not preloaded but are cached into the automatically refreshing cache
• the modules are preloaded and are cached into the automatically refreshing cache

In the sample page, the four conditions listed above are represented by four rows of iframes. The page gradually, one by one, loads the iframes — only one iframe is loaded at a time. To calculate a representative average loading time for each setting, ten iframes are loaded into each row.