This is the 30th day of my participation in the Wenwen Challenge

Without getting to the point, LET’s take a look at some of the optimizations we use in our projects: multithreading packaging, scaling down packaging, the idea of dynamic link libraries, and tree shaking.

HappyPack

Happypack is a tool that uses multiple threads to speed up webpack packaging. Small projects may not be obvious, but for large and medium-sized projects, Happypack can significantly reduce the packaging time.

The working principle of

Webapck needs to step by step to get deeper resources and then do a translation. The problem here is that WebPack is single-threaded, assuming that a module depends on several other modules, which WebPack must translate one by one. Although there is no relationship between the batches of translation tasks, they must be executed sequentially. HappyPack’s core feature is the ability to start multiple threads to translate different modules in parallel, making full use of local computing resources to speed up packaging.

Happypack is suitable for those projects with heavy translation work, generally applied to babel-Loader, TS-Loader, etc., for ass-Loader, less-loader itself consumption is not too much engineering effect.

use

Single Loader optimization

const HappyPack = require('happypack');
module.exports = {
    // ...
    module: {
        rule: [{test: /\.js$/,
                exclude: /node_modules/.
                loader: 'happypack/loader',}}]plugins: [
        new Happypack({
            loaders: [{loader: 'babel-loader'.options: {
                        presets: ['react']}}]})]}Copy the code

Multiple loader

const HappyPack = require('happypack');
module.exports = {
    // ...
    module: {
        rule: [{test: /\.js$/,
                exclude: /node_modules/.
                loader: 'happypack/loader? id=js'}, {test: /\.ts$/,
                exclude: /node_modules/.
                loader: 'happypack/loader? id=ts',}}]plugins: [
        new Happypack({
            id: 'js'.loaders: [{loader: 'babel-loader'.options: {
                        presets: ['react']}}]}),new Happypack({
            id: 'ts'.loaders: [{loader: 'ts-loader',}]})]}Copy the code

Shrink the packaging scope

From the macro perspective, there are no more than two ways to improve performance: increasing resources or narrowing the scope. Increasing resources means using more CPU and memory and more computing power to shorten the execution time of tasks. Narrowing down is about focusing on the task itself and trying not to do repetitive tasks.

Exclude and include

For JS, exclude node_modules. Exclude rules that overlap with incude takes precedence. It is written as follows:

 module: {
    rule: [{test: /\.js$/,
            include: /src\/sciprts/.
            loader: 'babel-loader',]}}Copy the code

noParse

NoParse can be used to ignore libraries that webapack does not want to parse, that is, we do not want to apply any loader rules, and there are no internal modules to the library.

module: {noParse: /lodash/  // function, return path
}
Copy the code

IgnorePlugin

Exclude and include specify the scope of the loader rule, noParse does not parse but is packed into the bundle, and IgnorePlugin excludes modules completely. Excluded modules will not be packed into the resource file even if they are referenced.

plugins:[
    new webpack.IgnorePlugin({
        resourceRegExp: /^\.\/locale$/.// Match the resource file
        contextRegExp: /moment$/.// Match the retrieved directory})]Copy the code

Dllplugin

DLL draws on the idea of dynamic link library. For third-party modules or some modules that do not change often, they can be pre-compiled and packaged, and then directly used in the actual construction of the project. DLL is similar to code splitting, both of which can be used to extract common modules, but code splitting is different in essence. The idea of code splitting is to set up specific rules and successfully extract modules based on those rules after packaging. DLL is completely separated from vendor, has its own set of Webpack configuration, and packaged independently, in the actual project construction, there is no need to do any processing to it, can be directly used. Therefore, DLLS are theoretically faster in packaging than Code Splitting, but also respond to increased configuration and resource management complexity. I will not write the specific code here, because it is a bit complicated, everyone may not set the same, please refer to the official website.

tree shaking

Es Module dependencies are built at compile time, not run time. Based on this feature, WebPack provides tree Shaking. It helps us detect modules in the packaging process that are not referenced in the project. This part of the code will never be executed, so it is also called dead code. Webpack will discard this code and remove it from the final bundle when the resource is compressed

Tree shaking only works for ES5 Modules. Sometimes we’ll see that the entire library is loaded just by using one interface in a library, and the size of the bundle does not decrease because of Tree shaking. This is probably due to the fact that the library is everywhere in CommonJS form, which is currently used by most NPM packages for better compatibility. There are some NPM packages that provide both ES Module and CommonJS everywhere. We should use es Module modules whenever possible to make tree Shaking more efficient.

Some optimization instructions about Webapck to this, when the theory look, code or look at the official website, the official website more detailed!!