Build-time is all the steps required to build a bundle of your web app. From TypeScript compilation to SASS and PostCSS compilation to source map generation to minification. You can measure build-time performance along two dimensions: timing and memory usage.

CPU Profiling Plugin and Timings

webpack’s ProfilingPlugin generates a JSON file showing which functions were called, how often, and how much CPU they used. In addition, they are grouped by the webpack plugins so you can see which ones are taking up the most time during the build process. Improving the overly slow parts is only possible with profiling data that identifies where the build-time performance bottlenecks are.

You can analyze the JSON file in Chrome Dev Tools’ Performance tab. However, larger builds may create JSON files over 100 MB, too large for Chrome Dev Tools. If the file is large, you can use 0x to view a flame graph. However, 0x may not display all the information. Instead, you can use the Node.js CPU profiling with webpack.

Heap Memory Profiling

heap-sampling-webpack-plugin is a plugin for webpack that uses the Node inspector to snapshot the build process’s memory usage. It is simple to set up, and it generates heap profile files. A heap profile contains a tree of function calls and the memory used and retained. You can view the heap profile files in the Memory tab of Chrome Dev Tools or VS Code. Both tools provide a tree of function calls to dive deep and discover where memory is being allocated and retained. Both Chrome Dev Tools and VSCode can display a flame graph, which is a more compact view and can be easier to navigate.

Here’s a video demonstrating how the heap profile looks like in Chrome Dev Tools:

It’s a very neat and practical plugin that reports peak memory usage, vital for continuous integration environments.

When profiling the memory usage, you must consider whether that part of the build process is necessary. Consider if particular webpack plugins or loaders have memory leaks or unique memory usage characteristics.

Example: optimization and realContentHash

For instance, the optimization configuration for webpack has a realContentHash setting. This setting enables webpack to process assets again to generate accurate content hashes: https://webpack.js.org/configuration/optimization/#optimizationrealcontenthash

Webpack uses an internal hash calculation when this setting is disabled. This internal hash calculation may yield different hashes for identical content. Typically, the realContentHash setting is enabled. You can see how much memory is used by the process of generating that real content hash in the heap profile. The realContentHash pass consumes much more memory when there are more assets. When more files are part of the build process, the build-time and memory usage may increase. To reduce memory usage, one option is to turn this setting off and accept the drawback. Another option is to crack open the webpack "optimization" plugin code and investigate the possibility of updating the realContentHash algorithm to consume less memory, for example, by redesigning the algorithm or by calling out to an optimized C/C++/Rust/Go or operating system utility function.

Read more here: https://rudolfolah.com/profiling-webpack-node-react/