1. 速度优化
平常开发打包配置你们都是习惯用脚手架等的默认配置，没问题，没毛病，跑的好好的，就没这么在乎。对于一些强迫症的患者，仍是会有点不爽的， 好比速度，好比最终打包出来的资源大小等等。
1.1 本地构建或者服务端构建
1.1.1 本地构建
开发完后本地构建，而后经过push到cnd同步资源。多是传统你们喜欢作的思路，没毛病，也挺好用的。
不足点：加剧了仓库的体积，对于仓库中的语义化的npm包，本地构建不能实时享受到包的更新。
优势： 适合于多人项目合做初期，或者依赖的一个三方包也处于一个不断迭代的过程，每一个人开发的过程当中仅仅打包本身的页面，互相不干扰
1.1.2 服务端构建
服务端构建，大体就是当资源push的时候，会在一台构建机器上面跑相似ci的服务，同时也会有打包的服务
优缺点基本就是本地的相反，可是仍是比较推荐这样的方案
1.2 如何来优化
1.2.1 配置差别化
粗暴点其实你们可能但愿这个配置能够自动化生成，并且能够仅有一份来作，思路是没错，可是其实应该作一些区分
|
功能
|
本地开发
|
线上发布
|
|
压缩代码
|
须要
|
|
|
babel-polyfill
|
通常不须要
|
看业务需求
|
|
分离样式
|
须要
|
|
|
删除console.log
|
须要
|
|
|
css Prefix
|
须要
|
|
|
OccurrenceOrderPlugin
|
须要
|
|
|
DedupePlugin
|
须要
|
|
|
Babel present转码
|
须要
|
其实比较合理的方式应该是用环境变量来区分进行不一样环境下不一样的配置，ps：设置环境变量为了在window兼容，可使用cross-env 来设置
以上的对比没有进行测试，感兴趣的同窗能够试试看，在老的基础上修改会有多少的优化。
总结起来就是本地开发只求速度快，能少处理一点是一点
1.2.2 常见方式
能够在社区中看到不少相关相似的文章来作webpack的优化，各类各样的提速，可能都知道，可是懒得作，但其实一旦完成后，带来的受益是巨大的。
externals
这多是最暴力最提速的方法之一，把其中的一些库从中忽略掉，若是extern react了，须要注意的是最好把相关的一些react-addons-transition-group也给extern掉，不然有可能会出现依然打入多份react的问题，由于react-addons-transition-group这样的包里面代码是相似以下方式，externals并不能排除
module.exports = require('react/lib/ReactTransitionGroup');
Dll
将一些可预见性的库从中抽离，预打包，能够极大的提速，当时仍是有蛮多须要注意的，好比一样的包最好全局只有一份，预打包后不能享受到语义化版本的资源跟新，须要结合实际问题来看是否须要。
HappyPack
经常使用套路加速
const os = require('os');
HappyPack.ThreadPool({size: os.cpus().length })
一些配置
设置一些alias，同时能够适当设置一些loaders中的exclude等
设置css-loader版本号
提速特别明显
"css-loader": "^0.14.5",
替换scss-loader 为fast-sass-loader
相比起来比scss-loader速度更快
不用webpack自带的uglfiyJS
用自带的uglfiyJS来作压缩速度比较慢，这边有俩思路，但原理应该是同样的
-
造个新轮子多核并行去压缩js和css
这个方案优化通常来讲能够提速一半左右
js和scss的分离
这个能够优化本地开发过程当中的rebuild速度，尽可能让scss文件和js文件分离，若是使用了一些ui库，能够引用UI库的css文件，而不是scss文件，省去每次的scss build过程
1.3 其余
-
对于打包webpack多是一个功能大而全的工具，除此以外还有不少相似于rollup或者是browserify，要看具体场景来使用，杀鸡可能选个更合适的刀会更好，不要盲目选择都是用一把刀。后续待尝试后详细再补相关的一些其余打包方案。
-
优化永无止境
2. 代码优化
2.1 精简node_modules
如今开发基本都是使用npm或者yarns进行依赖管理，随便引入几个依赖就会使得最终打包的结构臃肿，再加上开发者可能对依赖的包并无特别统一管理，须要什么就引入什么，不会去关心互相之间的关系。
上图仅仅是说明node_modules管理的时候出现的包的量一个图，能够说是很是的形象。
图片来自文章What’s really wrong with node_modules and why this is your fault，文章推荐一看
注：npm包开发者应该保证包里面仅只有须要的代码，好比测试等等的资源最好都忽略掉，这样也能够省去很多开支，细节后续会整理一篇新的文章。
2.1.1 方法1：一样功能使用一样的包
多人开发常会遇到使用三方库，部分人使用deep-extend，可是后面可能又有人用lodash，这样一来一回，会出现一样功能的包会引用多个的问题。对于这个状况不会致使bug，可是会形成node_modules增多且package.json依赖混乱，固然代码大小也会有相应的损失。
解决方式
查看仓库的package.json，好比
{
"deep-extend": "^0.4.1",
"lodash.clonedeep": "^4.5.0",
}
如上俩个库都是想作深拷贝，能够选择只使用其一便可，推荐
2.1.2 方法2：同一个包尽可能不存在多个版本
大部分状况这样仅只会加剧代码的体积等，可是在少数的场景下，好比使用了前端组件库；
举个例子，项目中依赖了俩组件A和B，A依赖了某UI库C的1.0.0的input，而B依赖了C中的2.0.0的input，最终页面上会同时存在俩版本的input，这里存在一个隐患（若是俩组件有Dom节点结构调整发生样式变化，这个时候不管是使用1.0.0或者是2.0.0的样式其实都不合适），因此这个问题也须要多关注的，特别是前端的UI库，最好习惯性的排查下较为好。必须最好作下
解决方式
打开chrome调试工具，查看node_modules，对于UI的库，仔细翻翻，不能有多版本的库，对于其余库则能够佛系排查；若是发现某个库A出现了屡次，可使用npm ls A来查看是在什么地方屡次引用到了，而后再定位到具体细节的包查看
2.1.3 方法3：分析代码依赖
使用webpack的使用BundleAnalyzerPlugin或者是用自带的功能输出json，进行分析，排查为何最后输出的资源这么大的缘由
2.2 抽离公用资源
比较适合那些整站的开发，将各个页面公用的资源抽离出来，这样在页面的访问过程当中浏览器能够很好的将这些通用资源缓存，相似使用dll存在本地工程中，还可使得打包加速，下面以dll为例
作法
-
配置好项目所要打的dll资源，通常选择的是一些三方的库，具体看项目的需求
-
预先打好dll的资源放到项目的某个自定目录中（甚至能够直接打成生产环境的版本省去后续的压缩）
-
本地构建或者服务端构建任务结束后，将打好的dll资源拷贝到build目录下面
注意点
-
若是使用服务端构建请务必保持本地的npm版本和服务端构建上面的版本一致，不一样的npm的版本可能会致使manifest.json的里面内容不一致，由于dll存的是路径
-
最好解决下同一个库多版本的问题，不然dll中就会打进去多版本的库，由于dll存路径不一样的版本的版本号是不一致的
2.3 其余
2.3.1 使用babel-preset-env
官方也是推荐使用它来代替babel-preset-2015，根据业务所须要适配的浏览器去选择合适的，不然使用多余的转码会是的代码转码后更大，同时对于browsers的设置，也能够跟postCss进行统一
2.3.2 区分好大包小包的问题
一些组件库或者是lodash
import { isEmpty } from 'lodash';
import isEmpty from 'lodash/isEmpty';
所产生的结果是不同的。除非使用一个转码的工具来支持；vscode用户建议装一个
Import Cost
2.3.3 升级打包工具webpack
升级到webpack3，有tree shaking、Scope Hoisting都对代码有着不错的优化
2.3.4 优化样式
-
prefix这类的工做交给postCss来完成，一样是根据业务的需求去作相关的prefix的处理，很少很多
-
精简样式，去除不必的样式