Why separate third-party libraries?

Webpack is a annoying little goblin. I have always been in the glut camp and used browserify for packaging. I found that webpack has exploded in popularity. I was afraid of being left behind by the community, so I quickly picked it up and played with it. Originally I just wanted to play. After trying to package, I want to start a webpack server, and then add hot replacement, separate css files, use various loaders to process and optimize the packaging results, and what are the differences between various source-maps? None of them can be missing. When adding hot replacement, there were some twists and turns because the application server and the webpack server did not use the same one. Then we come to today’s topic.
Gradually expand today’s topic:
Why should we separate third-party libraries?
This benefit is obvious. The third-party library is relatively stable and will not change easily. After using the browser cache, the user will reduce server requests and improve the speed optimization experience when the user loads the page again. The function of extracting common modules from multiple applications (entrances) is similar. The common parts will be cached, and all applications can use cached content to improve performance.
Can I use the browser to change the cache by separating the third-party library?
It is also obviously negative. There are many factors that lead to the inability to use the cache. For example, the most obvious one is that every time you repackage the separated library file, you will get a different name. This is easier to find. Another example is Colleagues in the background set the cache expiration time for the js file to 0, which is embarrassing, but if it is 0, the cache cannot be used? No, as long as the file is completely unchanged, note that it is completely unchanged, including the modification time, the cache will still be used, and the performance will skyrocket. If you want to use caching, you must first understand caching. Here is a brief mention:
What is the browser caching mechanism?
The strategy given by HTTP1.1 is to use Cache-control with Etag.
Cache-control setting example:
'Cache-Control': 'public, max-age=600',
max-age is the expiration time. If it has expired, you will also check the Etag.
The value of ETag:
In Apache, the value of ETag defaults to the index section (INode), size (Size) and The last modification time (MTime) is obtained after hashing.
If the Etag is the same, new resources will still not be requested, but the previous file will be used.
What is CommonsChunkPlugin used for?
Literally understood, extract the public package. The public package means that it is used in more than one place. The library of a single-page application (single entry) is only used by himself, so it cannot be considered a public package, right? The public package extracted by this plug-in will be repackaged every time (Etag will be different), whether it is to save packaging time (although it is trivial but it is useless after all: the library has not changed at all), or to use the browser cache (What if max-age expires? Will you give up caching?) Neither is a good solution. The best solution emerged: DllPlugin
What are the advantages of DllPlugin?
Package the library file only once. In other words, as long as the library file remains unchanged, it only needs to be packaged once. It doesn't matter if you package the business code and library file later. In this way, the library file will always be the same library file. As long as the library file remains unchanged, the cache will always be valid ( Etag remains unchanged), pack up the bag and forget about the library, feeling refreshed. Let me introduce the simplest way to use it:
First write another webpack configuration file. After all, it is a separate package library. Assume webpack.config.dll.js

const path = require('path')const webpack = require('webpack');module.exports = {
  entry: {vendor: ['react', 'react-dom', 'react-hot-loader', 'immutable', 'redux', 'react-redux', 'react-router-dom', 'redux-logger',  'redux-persist', 'redux-persist-transform-immutable', 'redux-thunk'],
  },
  output: {filename: 'js/[name].js',path: path.resolve(__dirname, 'public'),library: '[name]', // 当前Dll的所有内容都会存放在这个参数指定变量名的一个全局变量下，注意与DllPlugin的name参数保持一致
  },
  plugins: [new webpack.DllPlugin({  path: path.resolve(__dirname, 'public/manifest.json'), // 本Dll文件中各模块的索引，供DllReferencePlugin读取使用  name: '[name]',}),
  ],}

Add DllReferencePlugin plug-in to the original configuration file

new webpack.DllReferencePlugin({  manifest: require('./public/manifest.json'), // 指定manifest.json  name: 'vendor',  // 当前Dll的所有内容都会存放在这个参数指定变量名的一个全局变量下，注意与DllPlugin的name参数保持一致}),

Run the terminal first:
webpack -p --progress --config ./webpack.config.dll.js
Pack the library file into a package first. As long as the library remains unchanged, you will use this package in the future, and then package the business code and you are done.
Recommended strategy:
Everyone does his own thing.
If it is a single-page application, just use DllPlugin to package the library file, and the business code can be packaged in one package.
If it is a multi-page application, after DllPlugin packages the library files, a lot of public business codes may be used during development and may change at any time. In this case, CommonsChunkPlugin must be used to do what it is supposed to do, and then extract the public business code. , As for caching, at least the public parts will still be cached when switching between pages.

The above is the detailed content of Why separate third-party libraries?. For more information, please follow other related articles on the PHP Chinese website!