我们还能在哪些方面进行webpack性能优化

Bigo前端组计算平台前端组基于amis框架，参考之前的文章：>我们可以在js中引入样式文件
require('myStylecss')
这时我们便需要引入相应的webpack loader来帮助我们解析这段代码。
一般来说需要引入css-loader和style-loader，其中css-loader用于解析，而style-loader则将解析后的样式嵌入js代码。
// webpack配置如下
{
module: {
loaders: [
{ test: /\$/, loader: "style-loader!css-loader" }
]
}
}
可以发现，webpack的loader的配置是从右往左的，从上面代码看的话，就是先使用css-loader之后使用style-loader。
同理，如果你使用less来写样式的话，则需要先用less-loader来编译样式文件为css文件，再继续使用css-loader与style-loader。
{
module: {
loaders: [
{ test: /\$/, loader: "style-loader!css-loader!less-loader" }
]
}
}
我们知道，webpack配置loader时是可以不写loader的后缀明-loader，因此css-loader可以写为css。
将样式抽取出来为独立的文件
将require引入的样式嵌入js文件中，有好处也有坏处。好处是减少了请求数，坏处也很明显，就是当你的样式文件很大时，造成编译的js文件也很大。
我们可以使用插件的方式，将样式抽取成独立的文件。使用的插件就是extract-text-webpack-plugin
基本用法如下
var ExtractTextPlugin = require("extract-text-webpack-plugin");
moduleexports = {
module: {
loaders: [
{ test: /\css$/, loader: ExtractTextPluginextract("style-loader", "css-loader") }
]
},
plugins: [
new ExtractTextPlugin("stylescss")
]
}
根据插件在github上的解释，ExtractTextPluginextract可以有三个参数。
第一个参数是可选参数，传入一个loader，当css样式没有被抽取的时候可以使用该loader。
第二个参数则是用于编译解析的css文件loader，很明显这个是必须传入的，就像上述例子的css-loader。
第三个参数是一些额外的备选项，貌似目前只有传入publicPath，用于当前loader的路径。
那什么时候需要传入第一个参数呢，那就得明白什么时候样式不会被抽取出来。
了解过code splittiog的同学便会知道，我们有些代码在加载页面的时候不会被使用时，使用code splitting，可以实现将这部分不会使用的代码分离出去，独立成一个单独的文件，实现按需加载。
那么如果在这些分离出去的代码中如果有使用require引入样式文件，那么使用ExtractTextPlugin这部分样式代码是不会被抽取出来的。
这部分不会抽取出来的代码，可以使用loader做一些处理，这就是ExtractTextPluginextract第一个参数的作用。
根据上面的案例，ExtractTextPlugin需要配合plugin使用。
new ExtractTextPlugin([id: string], filename: string, [options])
该插件实例的唯一标志，一般是不会传的，其自己会生成。
文件名。可以是[name]、[id]、[contenthash]
[name]：将会和entry中的chunk的名字一致
[id]：将会和entry中的chunk的id一致
[contenthash]：根据内容生成hash值
options
allchunk： 是否将所有额外的chunk都压缩成一个文件
disable：禁止使用插件
这里的参数filename里如何理解呢？上述案例指定了一个固定的名字，因此便会生成一个stylescss文件。
那么像[name]、[id]这些如何理解。这个在你有多个entry的时候，便需要使用这种方式来命名。
var ExtractTextPlugin = require("extract-text-webpack-plugin");
moduleexports = {
entry: {
"script": "/src/entryjs",
"bundle": "/src/entry2js",
},

module: {
loaders: [
{ test: /\css$/, loader: ExtractTextPluginextract("style-loader", "css-loader") }
]
},
plugins: [
new ExtractTextPlugin("[name]css")
]
}
这时候便会生成两个css文件，一个是scriptcss，另一个便是bundlecss。那些[id]、[contenthash]也是一个道理。
只要明白，在你有多个entry是，一定要使用这种方式来命名css文件。
最后还有那个allchunks又是什么呢？很简单，还记得前面提到的code splitting么？将该参数配置为true，那么所有分离文件的样式也会全部压缩到一个文件上。
plugins: [
new ExtractTextPlugin("[name]css", {allChunks: true})
]
postcss
以前我们写样式时，有些样式不同浏览器需要加不同的前缀，如-webkit-。现在有了构建工具，我们便不需要再去关注这些前缀了，构建工具会自动帮我们加上这些前缀。
对于webpack我们自然想到需要使用loader或者plugin来帮助我们做这些事情，查了下发现autoprefixer-loader已经废弃不再维护了，推荐使用posscss
postcss是用于在js中转换css样式的js插件，需要搭配其他插件一起使用，这点和babel6一样，本身只是个转换器，并不提供代码解析功能。
这里我们需要autoprefixer插件来为我们的样式添加前缀。首先下载该模块。
npm install autoprefixer --save-dev
接着便可以配置webpack了
var autoprefixer = require('autoprefixer')
moduleexports = {

module: {
loaders: [

{
{
test: /\css$/,
loader: ExtractTextPluginextract(["css-loader", "postcss-loader"])
},
}
]
},
postcss: [autoprefixer()],

}
查看一下抽取出来的样式文件便可以发现已经加上了前缀
a {
display: flex;
}
/compiles to:/
a {
display: -webkit-box;
display: -webkit-flex;
display: -ms-flexbox;
display: flex
}
另外autoprefixer还可以根据目标浏览器版本生成不同的前缀个数，例如你的应用的使用用户如果大多数是使用比较新版本的浏览器，那么便可以做如下配置。
postcss: [autoprefixer({ browsers: ['last 2 versions'] })]
这是生成的样式便会有些不一样，还是上面的例子
a {
display: flex;
}
/compiles to:/
a {
display: -webkit-flex;
display: -ms-flexbox;
display: flex;
}
postcss后记
这里再说一个问题，有些童鞋可能会在css文件中使用@import引入其他样式文件，但是使用autoprefixer发现，import进来的样式没有处理，如下面所示：
/myStylecss:/
body {
background-color: gray;
}
flex {
display: flex;
}
/myStyle2css:/
@import "/myStylecss";
div {
color: red;
}
/autoprefixer之后/
body {
background-color: gray;
}
flex {
display: -webkit-box;
display: -webkit-flex;
display: -ms-flexbox;
display: flex;
}
body {
background-color: gray;
}
flex {
display: flex;
}
div {
color: red;
}
要解决这个问题，postcss有个解释，它让我们使用postcss-import插件，再配合autoprefixer
postcss: function(webpack) {
return [
postcssImport({
addDependencyTo: webpack
}),
autoprefixer
]
},
其实我们是不推荐使用@import的，心细的童鞋可以看到最后生成的样式文件有样式是重复的。
所以一般我们应该是在js中使用require来引入样式文件。可以参考的说法这里
样式压缩
压缩代码我们可以使用webpack的内置插件UglifyJsPlugin来做，它既可以压缩js代码也可以压缩css代码。
plugins: [

new webpackoptimizeUglifyJsPlugin({
compress: {
warnings: false
}
}),

]
其实并不能说是在压缩css代码，本质来说还是压缩js代码，再将这块代码输出到css文件中。
使用CommonsChunkPlugin抽取公共代码
首先要明确一点CommonsChunkPlugin是在有多个entry时使用的，即在有多个入口文件时，这些入口文件可能会有一些共同的代码，我们便可以将这些共同的代码抽取出来成独立的文件。明白这一点非常重要。（搞了很久才明白的一点，唉～～～～）
如果在多个entry中require了相同的css文件，我们便可以使用CommonsChunkPlugin来将这些共同的样式文件抽取出来为独立的样式文件。
moduleexports = {
entry: {
"A": "/src/entryjs",
"B": "/src/entry2js"
},

plugins: [
new webpackoptimizeCommonsChunkPlugin({name: "commons", filename: "commonsjs"}),

]
}
当然，这里不止会抽取共同的css，如果有共同的js代码，也会抽取成为commonsjs。
这里有个有趣的现象，抽取出来的css文件的命名将会是参数中name的值，而js文件名则会是filename的值。
CommonsChunkPlugin好像只会将所有chunk中都共有的模块抽取出来，如果存在如下的依赖
// entry1js
var style1 = require('/style/myStylecss')
var style2 = require('/style/stylecss')
// entry2js
require("/style/myStylecss")
require("/style/myStyle2css")
// entry3js
require("/style/myStyle2css")
使用插件后会发现，根本没有生成commonscss文件。
如果我们只需要取前两个chunk的共同代码，我们可以这么做
moduleexports = {
entry: {
"A": "/src/entryjs",
"B": "/src/entry2js",
"C": "/src/entry3js"
},

plugins: [
new webpackoptimizeCommonsChunkPlugin({name: "commons", filename: "commonsjs", chunks: ['A', 'B']}),

]
}

这里说明了，如果单纯使用html-webpack-plugin插件来处理html，那么在此插件下设置minify为false，就不会压缩html文件；但是如果使用了loader与html-webpack-plugin一起处理html，那么html的压缩还受loader的影响。
从你的描述来看，我估计是受了loader的影响了。

1 为什么用 webpack
他像 Browserify, 但是将你的应用打包为多个文件 如果你的单页面应用有多个页面, 那么用户只从下载对应页面的代码 当他么访问到另一个页面, 他们不需要重新下载通用的代码
他在很多地方能替代 Grunt 跟 Gulp 因为他能够编译打包 CSS, 做 CSS 预处理, 编译 JS 方言, 打包, 还有其他一些
它支持 AMD 跟 CommonJS, 以及其他一些模块系统, (Angular, ES6) 如果你不知道用什么, 就用 CommonJS
2 Webpack 给 Browserify 的同学用
对应地:
browserify mainjs > bundlejs
webpack mainjs bundlejs
Webpack 比 Browserify 更强大, 你一般会用 webpackconfigjs 来组织各个过程:
// webpackconfigjs
moduleexports = {
entry: '/mainjs',
output: {
filename: 'bundlejs'
}
};

---