React中型项目的优化实践（一）

写在前头—在公司搬砖也差不多一年了，眼看着项目越来越大，优化问题亟待解决。优化是一件很矛盾的事情，但是为了诗和远方，我们还是得走一趟坑坑洼洼的优化之路。

本文可能涉及的内容—

项目介绍

整个项目大概有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的静态页，可以将其脱离项目，写成静态页部署在其他的地方，但是不好的地方就是可能没法复用原项目组件。

方案二呢则是的方案，可以做到快速迁移，但是不好的地方在于迁移出去的页面其实还是塞在一个篮子里，只不过换了个新的篮子罢了。

方案三则是的方案，以时间作为成本，换来一个新的“低频页面项目”。具体要使用哪种方案，我觉得也是根据当前项目状况而定，不追求最完美，追求最合适。