React 16 加载性能优化指南

时间 2019-11-05

标签 react 加载性能优化指南栏目 React 繁體版

原文原文链接

关于 React 应用加载的优化，其实网上相似的文章已经有太多太多了，随便一搜就是一堆，已经成为了一个老生常谈的问题。javascript

但随着 React 16 和 Webpack 4.0 的发布，不少过去的优化手段其实都或多或少有些“过期”了，而正好最近一段时间，公司的新项目迁移到了 React 16 和 Webpack 4.0，作了不少这方面的优化，因此就写一篇文章来总结一下。css

零、基础概念

咱们先要明确一次页面加载过程是怎样的（这里咱们暂时不讨论服务器端渲染的状况）。html

用户打开页面，这个时候页面是彻底空白的；
而后 html 和引用的 css 加载完毕，浏览器进行首次渲染，咱们把首次渲染须要加载的资源体积称为 “首屏体积”；
而后 react、react-dom、业务代码加载完毕，应用第一次渲染，或者说首次内容渲染；
而后应用的代码开始执行，拉取数据、进行动态import、响应事件等等，完毕后页面进入可交互状态；
接下来 lazyload 的图片等多媒体内容开始逐渐加载完毕；
而后直到页面的其它资源（如错误上报组件、打点上报组件等）加载完毕，整个页面的加载就结束了。

因此接下来，咱们就分别讨论这些步骤中，有哪些值得优化的点。前端

一. 打开页面 -> 首屏

写过 React 或者任何 SPA 的你，必定知道目前几乎全部流行的前端框架（React、Vue、Angular），它们的应用启动方式都是极其相似的：java

html 中提供一个 root 节点

<div id="root"></div>
复制代码

把应用挂载到这个节点上

ReactDOM.render(
  <App/>,
  document.getElementById('root')
);
复制代码

这样的模式，使用 webpack 打包以后，通常就是三个文件：react

一个体积很小、除了提供个 root 节点之外的没什么卵用的html（大概 1-4 KB）
一个体积很大的 js（50 - 1000 KB 不等）
一个 css 文件（固然若是你把 css 打进 js 里了，也可能没有）

这样形成的直接后果就是，用户在 50 - 1000 KB 的 js 文件加载、执行完毕以前，页面是 完！全！空！白！的！。webpack

也就是说，这个时候：git

首屏体积（首次渲染须要加载的资源体积） = html + js + css
复制代码

1.1. 在 root 节点中写一些东西

咱们彻底能够把首屏渲染的时间点提早，好比在你的 root 节点中写一点东西：github

<div class="root">Loading...</div>
复制代码

就是这么简单，就能够把你应用的首屏时间提早到 html、css 加载完毕web

此时：

首屏体积 = html + css
复制代码

固然一行没有样式的 "Loading..." 文本可能会让设计师想揍你一顿，为了不被揍，咱们能够在把 root 节点内的内容画得好看一些：

<div id="root">
    <!-- 这里画一个 SVG -->
</div>
复制代码

1.2. 使用 html-webpack-plugin 自动插入 loading

实际业务中确定是有不少不少页面的，每一个页面都要咱们手动地复制粘贴这么一个 loading 态显然太不优雅了，这时咱们能够考虑使用 html-webpack-plugin 来帮助咱们自动插入 loading。

var HtmlWebpackPlugin = require('html-webpack-plugin');
var path = require('path');

// 读取写好的 loading 态的 html 和 css
var loading = {
    html: fs.readFileSync(path.join(__dirname, './loading.html')),
    css: '<style>' + fs.readFileSync(path.join(__dirname, './loading.css')) + '</style>'
}

var webpackConfig = {
  entry: 'index.js',
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'index_bundle.js'
  },
  plugins: [
    new HtmlWebpackPlugin({
      filename: 'xxxx.html',
      template: 'template.html',
      loading: loading
    })
  ]
};
复制代码

而后在模板中引用便可：

<!DOCTYPE html>
<html lang="en">
    <head>
        <%= htmlWebpackPlugin.options.loading.css %>
    </head>

    <body>
        <div id="root">
            <%= htmlWebpackPlugin.options.loading.html %>
        </div>
    </body>
</html>
复制代码

1.3. 使用 prerender-spa-plugin 渲染首屏

在一些比较大型的项目中，Loading 可能自己就是一个 React/Vue 组件，在不作服务器端渲染的状况下，想把一个已经组件化的 Loading 直接写入 html 文件中会很复杂，不过依然有解决办法。

prerender-spa-plugin 是一个能够帮你在构建时就生成页面首屏 html 的一个 webpack 插件，原理大体以下：

指定 dist 目录和要渲染的路径
插件在 dist 目录中开启一个静态服务器，而且使用无头浏览器（puppeteer）访问对应的路径，执行 JS，抓取对应路径的 html。
把抓到的内容写入 html，这样即便没有作服务器端渲染，也能达到跟服务器端渲染几乎相同的做用（不考虑动态数据的话）

具体如何使用，能够参考这一篇文章

plugins: [
  new PrerenderSpaPlugin(
    path.join(__dirname, 'dist'),
    [ '/', '/products/1', '/products/2', '/products/3']
  )
]
复制代码

1.4. 除掉外链 css

截止到目前，咱们的首屏体积 = html + css，依然有优化的空间，那就是把外链的 css 去掉，让浏览器在加载完 html 时，便可渲染首屏。

实际上，webpack 默认就是没有外链 css 的，你什么都不须要作就能够了。固然若是你的项目以前配置了 extract-text-webpack-plugin 或者 mini-css-extract-plugin 来生成独立的 css 文件，直接去掉便可。

有人可能要质疑，把 css 打入 js 包里，会丢失浏览器不少缓存的好处（好比你只改了 js 代码，致使构建出的 js 内容变化，但连带 css 都要一块儿从新加载一次），这样作真的值得吗？

确实这么作会让 css 没法缓存，但实际上对于如今成熟的前端应用来讲，缓存不该该在 js/css 这个维度上区分，而是应该按照“组件”区分，即配合动态 import 缓存组件。

接下来你会看到，css in js 的模式带来的好处远大于这么一丁点缺点。

二. 首屏 -> 首次内容渲染

这一段过程当中，浏览器主要在作的事情就是加载、运行 JS 代码，因此如何提高 JS 代码的加载、运行性能，就成为了优化的关键。

几乎全部业务的 JS 代码，均可以大体划分红如下几个大块：

基础框架，如 React、Vue 等，这些基础框架的代码是不变的，除非升级框架；
Polyfill，对于使用了 ES2015+ 语法的项目来讲，为了兼容性，polyfill 是必要的存在；
业务基础库，业务的一些通用的基础代码，不属于框架，但大部分业务都会使用到；
业务代码，特色是具体业务自身的逻辑代码。

想要优化这个时间段的性能，也就是要优化上面四种资源的加载速度。

2.1. 缓存基础框架

基础框架代码的特色就是必需且不变，是一种很是适合缓存的内容。

因此咱们须要作的就是为基础框架代码设置一个尽可能长的缓存时间，使用户的浏览器尽可能经过缓存加载这些资源。

附：HTTP 缓存资源小结

HTTP 为咱们提供了很好几种缓存的解决方案，不妨总结一下：

1. expires

expires: Thu, 16 May 2019 03:05:59 GMT
复制代码

在 http 头中设置一个过时时间，在这个过时时间以前，浏览器的请求都不会发出，而是自动从缓存中读取文件，除非缓存被清空，或者强制刷新。缺陷在于，服务器时间和用户端时间可能存在不一致，因此 HTTP/1.1 加入了 cache-control 头来改进这个问题。

2. cache-control

cache-control: max-age=31536000
复制代码

设置过时的时间长度（秒），在这个时间范围内，浏览器请求都会直接读缓存。当 expires 和 cache-control 都存在时，cache-control 的优先级更高。

3. last-modified / if-modified-since

这是一组请求/相应头

响应头：

last-modified: Wed, 16 May 2018 02:57:16 GMT
复制代码

请求头：

if-modified-since: Wed, 16 May 2018 05:55:38 GMT
复制代码

服务器端返回资源时，若是头部带上了 last-modified，那么资源下次请求时就会把值加入到请求头 if-modified-since 中，服务器能够对比这个值，肯定资源是否发生变化，若是没有发生变化，则返回 304。

4. etag / if-none-match

这也是一组请求/相应头

响应头：

etag: "D5FC8B85A045FF720547BC36FC872550"
复制代码

请求头：

if-none-match: "D5FC8B85A045FF720547BC36FC872550"
复制代码

原理相似，服务器端返回资源时，若是头部带上了 etag，那么资源下次请求时就会把值加入到请求头 if-none-match 中，服务器能够对比这个值，肯定资源是否发生变化，若是没有发生变化，则返回 304。

上面四种缓存的优先级：cache-control > expires > etag > last-modified

2.2. 使用动态 polyfill

Polyfill 的特色是非必需和不变，由于对于一台手机来讲，须要哪些 polyfill 是固定的，固然也可能彻底不须要 polyfill。

如今为了浏览器的兼容性，咱们经常引入各类 polyfill，可是在构建时静态地引入 polyfill 存在一些问题，好比对于机型和浏览器版本比较新的用户来讲，他们彻底不须要 polyfill，引入 polyfill 对于这部分用户来讲是多余的，从而形成体积变大和性能损失。

好比 React 16 的代码中依赖了 ES6 的 Map/Set 对象，使用时须要你本身加入 polyfill，但目前几个完备的 Map/Set 的 polyfill 体积都比较大，打包进来会增大不少体积。

还好比 Promise 对象，实际上根据 caniuse.com 的数据，移动端上，中国接近 94% 的用户浏览器，都是原生支持 Promise 的，并不须要 polyfill。但实际上咱们打包时仍是会打包 Promise 的 polyfill，也就是说，咱们为了 6% 的用户兼容性，增大了 94% 用户的加载体积。

因此这里的解决方法就是，去掉构建中静态的 polyfill，换而使用 polyfill.io 这样的动态 polyfill 服务，保证只有在须要时，才会引入 polyfill。

具体的使用方法很是简单，只须要外链一个 js：

<script src="https://cdn.polyfill.io/v2/polyfill.min.js"></script>
复制代码

固然这样是加载所有的 polyfill，实际上你可能并不须要这么多，好比你只须要 Map/Set 的话：

<script src="https://cdn.polyfill.io/v2/polyfill.min.js?features=Map,Set"></script>
复制代码

动态 polyfill 的原理

若是你用最新的 Chrome 浏览器访问这个连接的话：cdn.polyfill.io/v2/polyfill…，你会发现内容几乎是空的：

若是打开控制台，模拟 iOS 的 Safari，再访问一次，你会发现里面就出现了一些 polyfill（URL 对象的 polyfill）：

这就是 polyfill.io 的原理，它会根据你的浏览器 UA 头，判断你是否支持某些特性，从而返回给你一个合适的 polyfill。对于最新的 Chrome 浏览器来讲，不须要任何 polyfill，因此返回的内容为空。对于 iOS Safari 来讲，须要 URL 对象的 polyfill，因此返回了对应的资源。

2.3. 使用 SplitChunksPlugin 自动拆分业务基础库

Webpack 4 抛弃了原有的 CommonChunksPlugin，换成了更为先进的 SplitChunksPlugin，用于提取公用代码。

它们的区别就在于，CommonChunksPlugin 会找到多数模块中都共有的东西，而且把它提取出来（common.js），也就意味着若是你加载了 common.js，那么里面可能会存在一些当前模块不须要的东西。

而 SplitChunksPlugin 采用了彻底不一样的 heuristics 方法，它会根据模块之间的依赖关系，自动打包出不少不少（而不是单个）通用模块，能够保证加载进来的代码必定是会被依赖到的。

下面是一个简单的例子，假设咱们有 4 个 chunk，分别依赖了如下模块：

chunk	依赖模块
chunk-a	react, react-dom, componentA, utils
chunk-b	react, react-dom, componentB, utils
chunk-c	angular, componentC, utils
chunk-d	angular, componentD, utils

若是是之前的 CommonChunksPlugin，那么默认配置会把它们打包成下面这样：

包名	包含的模块
common	utils
chunk-a	react, react-dom, componentA
chunk-b	react, react-dom, componentB
chunk-c	angular, componentC
chunk-d	angular, componentD

显然在这里，react、react-dom、angular 这些公用的模块没有被抽出成为独立的包，存在进一步优化的空间。

如今，新的 SplitChunksPlugin 会把它们打包成如下几个包：

包名	包含的模块
chunk-a~chunk-b~chunk-c~chunk-d	utils
chunk-a~chunk-b	react, react-dom
chunk-c~chunk-d	angular
chunk-a	componentA
chunk-b	componentB
chunk-c	componentC
chunk-d	componentD

这就保证了全部公用的模块，都会被抽出成为独立的包，几乎彻底避免了多页应用中，重复加载相同模块的问题。

具体如何配置 SplitChunksPlugin，请参考 webpack 官方文档。

注：目前使用 SplitChunksPlugin 存在的坑

虽然 webpack 4.0 提供的 SplitChunksPlugin 很是好用，但截止到写这篇文章的时候（2018年5月），依然存在一个坑，那就是 html-webpack-plugin 还不彻底支持 SplitChunksPlugin，生成的公用模块包还没法自动注入到 html 中。

能够参考下面的 issue 或者 PR：

2.4. 正确使用 Tree Shaking 减小业务代码体积

Tree Shaking 这已是一个好久好久之前就存在的 webpack 特性了，老生常谈，但事实上不是全部的人（特别是对 webpack 不了解的人）都正确地使用了它，因此我今天要在这里啰嗦地再写一遍。

例如，咱们有下面这样一个使用了 ES Module 标准的模块：

// math.js
export function square(x) {
  return x * x
}

export function cube(x) {
  return x * x * x
}
复制代码

而后你在另外一个模块中引用了它：

// index.js
import { cube } from './math'
cube(123)
复制代码

通过 webpack 打包以后，math.js 会变成下面这样：

/* 1 */
/***/ (function(module, __webpack_exports__, __webpack_require__) {
 "use strict";
/* unused harmony export square */
/* harmony export (immutable) */ __webpack_exports__["a"] = cube;
function square(x) {
  return x * x;
}

function cube(x) {
  return x * x * x;
}
复制代码

注意这里 square 函数依然存在，但多了一行 magic comment：unused harmony export square

随后的压缩代码的 uglifyJS 就会识别到这行 magic comment，而且把 square 函数丢弃。

可是必定要注意！！！ webpack 2.0 开始原生支持 ES Module，也就是说不须要 babel 把 ES Module 转换成曾经的 commonjs 模块了，想用上 Tree Shaking，请务必关闭 babel 默认的模块转义：

{
  "presets": [
    ["env", {
      "modules": false
      }
    }]
  ]
}
复制代码

另外，Webpack 4.0 开始，Tree Shaking 对于那些无反作用的模块也会生效了。

若是你的一个模块在 package.json 中说明了这个模块没有反作用（也就是说执行其中的代码不会对环境有任何影响，例如只是声明了一些函数和常量）：

{
  "name": "your-module",
  "sideEffects": false
}
复制代码

那么在引入这个模块，却没有使用它时，webpack 会自动把它 Tree Shaking 丢掉：

import yourModule from 'your-module'
// 下面没有用到 yourModule
复制代码

这一点对于 lodash、underscore 这样的工具库来讲尤为重要，开启了这个特性以后，你如今能够无意理负担地这样写了：

import { capitalize } from 'lodash-es';
document.write(capitalize('yo'));
复制代码

3、首次内容渲染 -> 可交互

这一段过程当中，浏览器主要在作的事情就是加载及初始化各项组件

3.1. Code Splitting

大多数打包器（好比 webpack、rollup、browserify）的做用就是把你的页面代码打包成一个很大的 “bundle”，全部的代码都会在这个 bundle 中。可是，随着应用的复杂度日益提升，bundle 的体积也会愈来愈大，加载 bundle 的时间也会变长，这就对加载过程当中的用户体验形成了很大的负面影响。

为了不打出过大的 bundle，咱们要作的就是切分代码，也就是 Code Splitting，目前几乎全部的打包器都原生支持这个特性。

Code Splitting 能够帮你“懒加载”代码，以提升用户的加载体验，若是你没办法直接减小应用的体积，那么不妨尝试把应用从单个 bundle 拆分红单个 bundle + 多份动态代码的形式。

好比咱们能够把下面这种形式：

import { add } from './math';
console.log(add(16, 26));
复制代码

改写成动态 import 的形式，让首次加载时不去加载 math 模块，从而减小首次加载资源的体积。

import("./math").then(math => {
  console.log(math.add(16, 26));
});
复制代码

React Loadable 是一个专门用于动态 import 的 React 高阶组件，你能够把任何组件改写为支持动态 import 的形式。

import Loadable from 'react-loadable';
import Loading from './loading-component';

const LoadableComponent = Loadable({
  loader: () => import('./my-component'),
  loading: Loading,
});

export default class App extends React.Component {
  render() {
    return <LoadableComponent/>;
  }
}
复制代码

上面的代码在首次加载时，会先展现一个 loading-component，而后动态加载 my-component 的代码，组件代码加载完毕以后，便会替换掉 loading-component。

下面是一个具体的例子：

以这个用户主页为例，起码有三处组件是不须要首次加载的，而是使用动态加载：标题栏、Tab 栏、列表。首次加载实际上只须要加载中心区域的用户头像、昵称、ID便可。切分以后，首屏 js 体积从 40KB 缩减到了 20KB.

3.2. 编译到 ES2015+ ，提高代码运行效率

现在大多数项目的作法都是，编写 ES2015+ 标准的代码，而后在构建时编译到 ES5 标准运行。

好比一段很是简洁的 class 语法：

class Foo extends Bar {
    constructor(x) {
        super()
        this.x = x;
    }
}
复制代码

会被编译成这样：

"use strict";

function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

function _possibleConstructorReturn(self, call) { if (!self) { throw new ReferenceError("this hasn't been initialised - super() hasn't been called"); } return call && (typeof call === "object" || typeof call === "function") ? call : self; }

function _inherits(subClass, superClass) { if (typeof superClass !== "function" && superClass !== null) { throw new TypeError("Super expression must either be null or a function, not " + typeof superClass); } subClass.prototype = Object.create(superClass && superClass.prototype, { constructor: { value: subClass, enumerable: false, writable: true, configurable: true } }); if (superClass) Object.setPrototypeOf ? Object.setPrototypeOf(subClass, superClass) : subClass.__proto__ = superClass; }

var Foo = function (_Bar) {
  _inherits(Foo, _Bar);

  function Foo(x) {
    _classCallCheck(this, Foo);

    var _this = _possibleConstructorReturn(this, (Foo.__proto__ || Object.getPrototypeOf(Foo)).call(this));

    _this.x = x;
    return _this;
  }

  return Foo;
}(Bar);
复制代码