【第1075期】webpack 应用编译优化之路

前言

本文由滴滴出行@苗典授权分享。

正文从这开始～

目前大家使用最多也是最广泛的应用打包工具就是 webpack 了，除去 webpack 本身已经提供的优化能力（例如，Tree Shaking、Code Splitting 等）之外，我们还能做哪些事情呢，本篇主要就为大家介绍下滴滴 WebApp 团队在这条路上的一些探索。

现在越来越多的项目都使用 ES2015+ 开发，并且搭配 webpack + babel 作为工程化基础，并通过 NPM 去加载第三方依赖库。同时为了达到代码复用的目的，我们会把一些自己开发的组件库或者是 JSSDK 抽成独立的仓库维护，并通过 NPM 去加载。

大部分人已经习惯了这样的开发方式，并且觉得非常方便实用。但在方便的背后，却隐藏了两个问题：

代码冗余

一般来说，这些 NPM 包也是基于 ES2015+ 开发的，每个包都需要经过 babel 编译发布后才能被主应用使用，而这个编译过程往往会附加很多“编译代码”；每个包都会有一些相同的编译代码，这就造成大量代码的冗余，并且这部分冗余代码是不能通过 Tree Shaking 等技术去除掉的。

非必要的依赖

考虑到组件库的场景，通常我们为了方便一股脑引入了所有组件；但实际情况下对于一个应用而言可能只是用到了部分组件，此时如果全部引入，也会造成代码冗余。

代码的冗余会造成静态资源包加载时间变长、执行时间也会变长，进而很直接的影响性能和体验。既然我们已经认识到有此类问题，那么接下来看看如何解决这两个问题。

核心

我们对于上述的 2 个问题，核心的解决优化方案是：后编译和按需引入。

效果

先来看下滴滴车票项目（用票人）优化前后的数据（非 gzip，压缩后整个项目的大小）：

• 普通打包：455 KB

• 后编译：423 KB

• 后编译 & 按需引入：388 KB

• 后编译 & 按需引入 & babel-preset-env：377 KB

最终减少了约 80 KB，优化效果还是相当可观的。

上边的数据主要是对组件库和一些内部通用 JSSDK 采用后编译和按需引入策略后的效果，需要注意的是按需引入的效果是要视项目情况而定的，这里的数据仅供参考。

下面就分别来看看这两个点的具体细节。

后编译

先来解释下：

后编译：指的是应用依赖的 NPM 包并不需要在发布前编译，而是随着应用编译打包的时候一块编译。

后编译的核心在于把编译依赖包的时机延后，并且统一编译；先来看看它的 webpack 配置。

配置

对具体项目应用而言，做到后编译，其实不需要做太多，只需要在 webpack 的配置文件中，包含需要我们去后编译的依赖包即可（webpack 2+）：

// webpack.config.js
module.exports = {
    
  // ...
  module: {
    
    rules: [
      // ...
      {
    
        test: /\.js$/,
        loader: 'babel-loader',
        // 注意这里的 include
        // 除了 src 还包含了额外的 node_modules 下的两个包
        include: [
            resolve('src'),
            resolve('node_modules/A'),
            resolve('node_modules/B')
          ]
      },
      // ...
    ]