The core of optimizing front-end build time is to reduce redundant work, improve processing efficiency, utilize caches and select efficient tools. 1. Use Tree Shaking and code segmentation reasonably to ensure that on-demand introduction and dynamic imports are introduced to reduce packaging volume; 2. Reduce unnecessary loader processing, exclude node_modules, upgrade loaders and relax Babel translation scope; 3. Use the caching mechanism to speed up repeated construction, enable Webpack cache, CI cache and use offline installation; 4. Upgrade toolchain, such as using Vite, esbuild or Rollup to improve construction speed, although there is migration cost, it has significant effect.

As the front-end construction time takes a long time, development efficiency will easily be slowed down. Especially after the project becomes larger, each build starts in a few minutes, which will affect the CI/CD process, and local debugging will not be so smooth. Optimizing the build time is not to show off skills, but to make the entire development process more efficient.

The following points are relatively effective practices in actual projects. Not every one is applicable, but at least it can provide some ideas.

1. Use Tree Shaking and code segmentation rationally

Tree shaking is a function supported by modern packaging tools (such as Webpack and Vite) by default, and can automatically eliminate unused code. But the premise is that your project structure and dependencies are "shaking", such as introducing modules in the form of ES Module.

• Don't abuse import * as , try to introduce it as needed
• Use dynamic import ( import() ) for routing or component-level code segmentation
• Check whether third-party libraries also support tree-shaking. Some old libraries may package a lot of useless code.

For example: If you use a tool library like Lodash, import _ from 'lodash' will package the entire library and replace it with import debounce from 'lodash/debounce' will be much smaller.

2. Reduce unnecessary loader processing

Tools such as Webpack handle various types of files through loaders, but not every file needs to be processed by a bunch of loaders. Especially when Babel translates JS files, if you process too many files, it is easy to slow down the construction speed.

suggestion:

• Exclude node_modules directory and do not let it go to Babel compilation
• Use more efficient loaders for resources such as pictures, fonts, etc., such as replacing url-loader with asset modules (Webpack 5 built-in)
• If you don't need to be compatible with too old browsers, appropriately relax Babel's target environment and reduce translations

Sometimes you will find that Babel accounts for more than 30% of the time when building a project. At this time, the loader configuration can be significantly faster by optimizing it.

3. Use the cache mechanism to speed up repeated construction

Whether it is local development or CI construction, turning on cache can significantly improve the speed of secondary construction. Webpack 4 supports persistent cache, and Vite also starts in seconds with esbuild and native ESM in dev mode.

What you can do:

• Turn on cache: true or configure filesystem cache
• Cache node_modules and build cache directories in CI (such as .vite, webpack/cache)
• Reduce network requests using the --prefer-offline parameter of yarn/npm

The cache strategy is simple and effective, especially in CI, and one hit cache can save dozens of seconds or even more.

4. Upgrade the toolchain and select faster build tools

This is not the first priority, but it is critical in some scenarios. For example, Vite is based on browser native ESM in development mode, and it almost does not need to be packaged, and the startup speed is much faster than Webpack; while Snowpack and esbuild are more focused on extremely fast construction.

If your project allows you to try new tools, consider:

• Switch the development model to Vite, retaining the Webpack packaging production environment
• Using esbuild to handle TypeScript or JSX, far faster than Babel TSC
• Evaluate whether Rollup is more suitable for your library project

Of course, this step requires a certain migration cost and is suitable for the medium-term reconstruction stage.

Basically that's it. Optimizing the front-end construction time is the core of "doing less", "doing things quickly", and "doing things repeatedly". Each item does not seem complicated, but it works very well when combined.

The above is the detailed content of Frontend Build Time Optimization. For more information, please follow other related articles on the PHP Chinese website!