本文可能涉及的内容--
项目介绍
整个项目大概有60+个页面，用到的组件大概150+，package里面的依赖大概有70+个，应该勉强算得上是一个中型的React的项目了。
下面给大家看看我们现在build一次项目的结果--
打包时间约150s，打包完之后的资源gzip之后约1.2m，尽管之前分离了一些公用依赖，但是index包的体积达到了600+还是令人难以接受的。
需要解决的问题 && 思考过的方案
开始优化之前，最重要的就是搞清楚我们到底要优化什么。确定了优化的目标才能着手思考优化方案，进而实施优化方案。结合对项目的bundle分析以及自身对项目的了解，我们初步可以定出以下几点优化方向--
① 体积瘦身
首先我们需要足够了解我们的项目，才能着手进行瘦身。在这里有一个很给力的工具可以推荐给大家webpack-bundle-analyzer
盗用一下github上的图
如图所示，我们可以很清晰的看到每个js文件里的module组成，还可以看到每个module的大小以及module的组成成分，这对我们分析代码冗余以及优化方向都能够提供很大的帮助。
具体食用方式也很简单--
这样一来我们就对项目有了一个比较具体的认识，大到项目的依赖一览，小到某个页面的组件引用都能在分析报告中找到。接下来就可以开始我们的瘦身之旅了。
打团先找大哥
当我们第一次看到bundle的分析报告时，总能找到一些出乎意料的“大个子”，如果是必不可缺的依赖则没办法，但如果是一些可以被取代的依赖就有别的说法了。这里刚好可以看看之前我对create-react-app中moment.js依赖的处理，如果处理顺利的话可以很直观的看到bundle大小的变化。
总结来说，如果有小的并且满足需求的依赖可以替换，请不要迟疑；但如果没有可满足的依赖，可以尝试自己造一个轮子，当然后者需要结合自身状况考虑。
分散站位
相信大家在开发网站的时候都用到了不少依赖，但是这些依赖在输出之后是和业务代码打包在一起的，这个明显不符合我们的预期。面对这些基本不会变更的依赖，我们更倾向它们能够主动抱团并且远离我们的业务代码。
这时候，就该使用webpack的CommonsChunkPlugin（貌似在wp4中已经被别的插件替代了，在此我们先不讨论wp4），它可以帮助我们将一些指定的module打包进指定的bundle里。具体使用方案可以参考wp官网中的相关介绍，有一个坑点就是--倘若希望负责集合依赖bundle的文件名在打包时不变，则需要生成manifest。
不要将页面都放到一个篮子里（一）-- 页面分离
我们可以将一些低频页面彻底拉出项目，拿我们的项目来说，一共60+个页面，用户大多都是只会访问其中的几个或十几个页面，不可能将所有的页面都访问一遍。这样一来就必然会有一些页面的访问频率相比之下会十分低下，该怎么处理这些页面呢？这里有几种方案：
- 脱离框架重写相关页面并重新部署
- Copy项目代码，在其他地方重新跑一次并部署，原项目就可以删除不需要的页面
- 上一方案的简化版，复刻项目环境，跑一个新的纯净项目并部署，将原项目低频页面“剪切”到新的项目中
以上三种方案个人觉得各有优劣，第一个方案很简单，适用场景就是类似Q&A的静态页，可以将其脱离项目，写成静态页部署在其他的地方，但是不好的地方就是可能没法复用原项目组件。
方案二呢则是时间至上的方案，可以做到快速迁移，但是不好的地方在于迁移出去的页面其实还是塞在一个篮子里，只不过换了个新的篮子罢了。
方案三则是质量至上的方案，以时间作为成本，换来一个新的“低频页面项目”。具体要使用哪种方案，我觉得也是根据当前项目状况而定，不追求最完美，追求最合适。
② 首屏加载
首屏加载，大概是优化的永恒话题，所有的优化都避不开这一个话题，因为只有它能最直观的让“大家”都感受到我们这次优化的成果。对于用户来说，认为网页首屏很快的标准其实很单一，就是一打开页面，看了多久的白屏。所以我们需要做的就是弱化用户对白屏的感知，围绕这一点，个人认为，首屏加载这一优化可以有两个方向：一个是速度，另一个是体验。
引入加载占位
其实这个就是前段时间很火的“骨架屏”，我们可以在页面真正被渲染出来之前，先给用户看到一个“假的”页面,等到某个时间节点（例如数据已经准备完毕...）就将真正的内容替换上去。这里有一个我写的很不走心的例子:)
在这个优惠券列表页面我的处理方案是，初始化页面的时候就渲染3个列表项骨架，等待接口数据返回就将真实内容替换上去。
在我们的首屏其实也是类似的，我们可以根据首屏的展示结构，做一个匹配的骨架组件，然后按需求进行展示即可，这样可以有效减少用户看到白屏的时间。下面是我这个骨架的代码，优化的空间很大，不过由于优先级不是很高，所以就没有进行迭代了。
大概结构就是这样，样式方面很粗暴，因为每一项都是独立的一个组件，直接可以用absolute定位堆砌一个简洁的占位列表项。里面那个类似进度条的效果则是通过css3的animation实现的，我们可以将每个block的背景色变成渐变的，然后通过background-positon的变化来达到图中的效果。
图片懒加载
这应该是个老生常谈的优化方向了，原理大概是将视图之外的图片都用同一个占位图进行占位，将其真正的图链接存在data-*中，通过监听滚动来判断图片是否进入视图中，来控制img标签src的值。具体的实现很多地方都能搜到，大家可以根据自身情况，按需选择。
不要将页面都放到一个篮子里（二）-- 懒加载
其实在整个优化过程中我的重心是放在这个地方的，其他的都是半路上想到的...
让我们回想一下，上面我们讲过将低频页面分离，那么，必然就有会那么几个访问量十分高的页面，那么对于这几个页面应该怎么办呢？
因为访问频率高，所以我们可以认为这些页面与我们的核心业务是强相关的，所以将其分离就显得不那么划算了（很可能会出现维护多套代码的窘况）。
但是这样高频页面才是优化的重点区域呀，应该怎么办呢？面对这样页面我们还是可以使用懒加载大法（页面懒加载 || 组件懒加载 || 依赖懒加载）。
想要在js层面实现各类懒加载，我们都需要借助webpack中的特性Code Splitting，它可以将我们本来打包在一起的js分解成一块一块，并能达到按需加载并使用的效果。
- 页面懒加载
因为我们使用了react-router，所以我们可以使用react-router的getComponent轻松达到页面懒加载这一需求。如下图所示，将mainpage这样引入route的话，在打包的时候会将其分离成一个独立的js。
- 组件懒加载 && 依赖懒加载
组件和依赖的懒加载也是十分简单的，如下图这样写就能达到懒加载的效果，但如果我们使用了babel则需要修改一下babel的配置，让它能够顺利解析动态import()的语法。
③ 打包提速
我们通常的优化都是为了用户而优化，但其实为了我们自身能够良好的开发体验，也应该为开发人员优化优化开发体验，打包优化则成了不二之选。
使用DLL为打包保驾护航
由于时间原因，在公司的项目中并没有尝试使用DLL，但是看到网上有不少同学都推荐介绍了它，所以我选择在此提及一下~有关于webpack DLL的文档
将webpack版本从2.0 --> 4.x
由于项目是在差不多一年多以前正式启动的，所以接手的时候是webpack1.x，在刚接手的时候为了懒加载硬是升级到了2.x。
但是到现在发现，2.x好像也不够用了，毕竟已经落下了两个大版本了，更新之后的新特性、新功能或是新优化都应该成为我将项目迁移至新版本的动力。wp4具体的配置细节，在掘金上就见到过挺多同学介绍的，这里我想介绍一下，我是怎么将旧项目迁移到wp4的：
在开始进行版本迁移之前，我设想了两个方案，一个是在原有项目上直接升级并修改配置；第二个方案是新建webpack4项目，搭建好之后将业务代码迁移过来。
经过对成功率以及时间成本的评估，我最后选择的是第二个方案。那么这个新建的项目应该完善到什么程度才能进行迁移呢？我个人是经过以下几个步骤--
- 搭建项目骨架
这回的项目和之前的都不太一样了，我们没有借助大神们的脚手架来搭建项目骨架了，我们需要自己从零开始一点一点的摸索webpack的用法以及新旧版本的差异。
关于一些基础的知识以及配置十分推荐查阅webpack官网的文档以及一些之前参考过的文章webpack4-用之初体验、webpack 4.0.0-beta.0 新特性介绍。
相信大家看完这些之后都会对wp的配置有基本的认知，紧接下来就是建目录、装依赖巴拉巴拉。最终我们会得到一个这样的目录结构--
- 写个Hello World!
我们应该如何判断将项目代码迁入新项目的时机呢？很简单，当这个新项目可以正常的调试或打包一个相应框架的Hello World即可。
拿我们的项目来说，搭建完项目目录以及一些基础配置之后，接下来就是完全模拟原有项目的技术栈，在新的项目中写几个简单的demo页。当然这些demo页并不是随便写的，是带有目的性的，按我这次的经历来说，我写了这么几个文件index.js、App.js、Hello.js、Global.scss、router.js。
剥开非核心依赖，我们最核心的依赖其实就是react & react-router & sass，只要webpack能够正确的解析es6和sass我们就能很大程度的还原旧项目的环境。（babel中与jsx相关的配置在package里）
- 仔细研读package
上面的demo完成之后，我们新项目就初具雏形了，接下来我们就需要将旧项目package.json迁移到新项目中，这里需要注意的几点是：
① "scripts"中的指令要注意，我们要看里面的每条指令分别有什么作用，然后再思考应该怎么在新项目中写一个功能一样的指令。
② "dependencies" && "devDependencies"旧项目的依赖也应该无缝迁移过来，不过我们可以趁这个机会把没有用到的依赖剔除出去。
③ "babel" || "autoprefixer"等辅助工具的配置也应该与旧项目保持一致。
- 迁移项目&修修补补
上述步骤都跑通之后，就能删掉原有的demo，将旧项目的所有业务代码都迁移过来。接下来就看着报错，一个一个修复即可。这里遇到这么几个坑，困扰了我许久。页面很顺利的迁移过来了，依赖补全之后也顺利的跑起来了。
但是在dev环境下切换页面老是会404。相信大家看到这里就懂了，我用了history模式的路由，在devServer中应该要加上这样一行配置
devServer {historyApiFallback: true
}
复制代码好啦，404消灭之后又有新的状况了，静态资源老是引用不到，这是为啥？其实这是因为我们在output的时候没有设置publicPath引起的，在dev的webpack.config中我的output是这样配置的
output: {path: path.resolve('dist'),publicPath: '/'
},
// ...
devServer = {contentBase: './dist',port: 9000,historyApiFallback: true
}
复制代码这个问题解决之后，我们的开发环境算是还原的差不多了。接下来就该踩踩打包的坑了，我遇到的第一个问题就是，打包完成之后，文件夹里面只有打包输出，index.html咋不见了...这说好的不太一样。后面发现是少了copy-webpack-plugin
const CopyWebpackPlugin = require('copy-webpack-plugin')
const config = {// ...plugins: [new CopyWebpackPlugin([{from: 'public', to: ''}])]
}
复制代码加上这个依赖之后，我们public文件夹的内容就会乖乖的在dist里面出现。但紧接着又出现新的问题了，第二次打包的时候，怎么dist没有被清空呢？和上面一样，年轻的我少用了一个插件clean-webpack-plugin
const CleanWebpackPlugin = require('clean-webpack-plugin')
const CopyWebpackPlugin = require('copy-webpack-plugin')
let cleanOptions = {root: path.join(__dirname, '..'),verbose: true,dry: false
}
const config = {// ...plugins: [new CleanWebpackPlugin(['dist'], cleanOptions),new CopyWebpackPlugin([{from: 'public', to: ''}])]
}
复制代码完成上述配置后，每次打包webpack都会清空dist文件夹，并且在打包完成之后，将public中的内容复制到dist。好了看来应该可以了，但是在本地开了个服务器跑页面的时候发现，各种静态资源404。这又是什么玩意？实话说在这里踩坑时间是最多的，但是解决方案又是令人窒息的简单...都怪自己没有好好看文档
const CleanWebpackPlugin = require('clean-webpack-plugin')
const CopyWebpackPlugin = require('copy-webpack-plugin')
let cleanOptions = {root: path.join(__dirname, '..'),verbose: true,dry: false
}
const config = {output: {filename: 'static/js/[name].[chunkhash:8].js',chunkFilename: 'static/js/[name].[chunkhash:8].chunk.js',publicPath: 'http://localhost:5000/' // !!!这里一定要使用绝对路径，不然就会被坑到}// ...plugins: [new CleanWebpackPlugin(['dist'], cleanOptions),new CopyWebpackPlugin([{from: 'public', to: ''}])]
}
复制代码总结
好了，不知道有多少同学会看到这里，先谢谢大家看我在这唠叨一堆~各类优化的方案在网上看了好多好多，但是好像大家都只讲方案没有涉及实践，等到自己真正去玩的时候才发现，其实优化没有想象中那么简单，要兼顾原有的，又要尽量使用更新更好的，很多时候都会在夹缝中取舍。
对了，好像忘记放懒加载优化后的图了（还是wp2打包的），效果可能没有想象中那么理想吧，但也算往前踏出很不容易的一步了:)
其实，能够优化的还有很多很多，请求方面、业务方面甚至是代码写法...都是可以优化的，但是这些怎么能一蹴而就呢？还是得走一步，看一步，选择最适合自家项目的优化方案才是最佳方案~
