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

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

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180613G21LG000?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券