乐趣区

关于vite:Vite-项目性能分析与优化

jiezi

性能优化始终是前端工程化中陈词滥调的话题，也是前端我的项目优化的重要的优化点。事实上，随着我的项目越来越宏大，稍不留神就会产生显著的性能问题。在不同的场景中，咱们对于我的项目性能的关注点是不一样的。在我的项目开发阶段，咱们须要关注开发体验，重视我的项目构建性能；而在生产环境中，咱们个别更看重我的项目在的线上运行时性能。

对于开发阶段的构建性能问题，Vite 外部曾经做了相当多的优化，实现了我的项目秒级启动与毫秒级热更新，具体实现就不属于本文探讨的领域了，本文所介绍的性能优化次要指线上环境的我的项目加载性能优化，与页面的 FCP、TTI 等指标。

对于 Vite 我的项目的加载性能优化，常见的优化伎俩重点关注上面三个方面：

  • 网络优化。包含 HTTP2、DNS 预解析、Preload、Prefetch 等伎俩。
  • 资源优化。包含构建产物剖析、资源压缩、产物拆包、按需加载等优化形式。
  • 预渲染优化，本文次要介绍服务端渲染 (SSR) 和动态站点生成 (SSG) 两种伎俩。

不过，无论是以上哪一类优化形式，都离不开构建工具的反对，也就是说，在这些性能优化的场景中，咱们将高频地应用到 Vite，对 Vite 自身的构建能力进行深度地利用或者定制。

一、网络优化

1.1 HTTP2

传统的 HTTP 1.1 存在队头阻塞的问题，同一个 TCP 管道中同一时刻只能解决一个 HTTP 申请，也就是说如果以后申请没有解决完，其它的申请都处于阻塞状态，另外浏览器对于同一域名下的并发申请数量都有限度，比方 Chrome 中只容许 6 个申请并发，也就是说申请数量超过 6 个时，多进去的申请只能排队、期待发送。

因而，在 HTTP 1.1 协定中，队头阻塞和申请排队问题很容易成为网络层的性能瓶颈。而 HTTP 2 的诞生就是为了解决这些问题，只有体现在如下的能力上：

  • 多路复用。将数据分为多个二进制帧，多个申请和响应的数据帧在同一个 TCP 通道进行传输，解决了之前的队头阻塞问题。而与此同时，在 HTTP2 协定下，浏览器不再有同域名的并发申请数量限度，因而申请排队问题也失去了解决。
  • Server Push，即服务端推送能力。能够让某些资源可能提前达到浏览器，比方对于一个 html 的申请，通过 HTTP 2 咱们能够同时将相应的 js 和 css 资源推送到浏览器，省去了后续申请的开销。

在 Vite 中，咱们能够通过 vite-plugin-mkcert 在本地 Dev Server 上开启 HTTP2，应用前须要先装置这个插件：

npm i vite-plugin-mkcert -D

而后，在 Vite 配置中进行应用：

// vite.config.ts
import {defineConfig} from "vite";
import react from "@vitejs/plugin-react";
import mkcert from "vite-plugin-mkcert";


export default defineConfig({plugins: [react(), mkcert()],
  server: {
    // https 选项须要开启
    https: true,
  },
});

插件的原理也比较简单，因为 HTTP2 依赖 TLS 握手，插件会帮你主动生成 TLS 证书，而后反对通过 HTTPS 的形式启动，而 Vite 会主动把 HTTPS 服务降级为 HTTP2。

应用上 HTTP2 之后，在某些状况下大量并行申请的问题会失去显著的改善，这里有一个多申请的示例我的项目，下载实现之后再执行如下的命令：

npm run generate

即可生成 100 个 jsx 文件，咱们在弱网环境下测试，这样比照的成果更加显著，理论状况如下：

能够看到，以页面首屏绘制的工夫 (FCP) 来看，在开启了 HTTP2 之后，页面性能能够优化 60% 以上。而反观 HTTP 1.1 下的体现，不难发现大部分的工夫开销用用在了申请排队下面，在并发申请很多的状况下性能直线降落。

因而，对于线上的我的项目来说，HTTP2 对性能的晋升十分可观，简直成为了一个必选项。而刚刚演示用到的 vite-plugin-mkcert 插件仅用于开发阶段，在生产环境中咱们会对线上的服务器进行配置，从而开启 HTTP2 的能力，如果是用的 Nginx，能够参考：Nginx 的 HTTP2 配置。

1.2 DNS 预解析

浏览器在向跨域的服务器发送申请时，首先会进行 DNS 解析，将服务器域名解析为对应的 IP 地址。咱们通过 dns-prefetch 技术将这一过程提前，升高 DNS 解析的延迟时间，具体应用形式如下:

<!-- href 为须要预解析的域名 -->
<link rel="dns-prefetch" href="https://fonts.googleapis.com/">

个别状况下 dns-prefetch 会与 preconnect 搭配应用，前者用来解析 DNS，而后者用来会建设与服务器的连贯，建设 TCP 通道及进行 TLS 握手，进一步升高申请提早。应用形式如下所示:

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>
<link rel="dns-prefetch" href="https://fonts.gstatic.com/">

值得注意的是，对于 preconnect 的 link 标签个别须要加上 crorssorigin(跨域标识)，否则对于一些字体资源 preconnect 会生效。

1.3 Preload/Prefetch

对于一些比拟重要的资源，咱们能够通过 Preload 形式进行预加载，即在资源应用之前就进行加载，而不是在用到的时候才进行加载，这样能够使资源更早地达到浏览器。具体应用形式如下:

<link rel="preload" href="style.css" as="style">
<link rel="preload" href="main.js" as="script">

其中咱们个别会申明 href 和 as 属性，别离示意资源地址和资源类型。Preload 的浏览器兼容性也比拟好，目前 90% 以上的浏览器曾经反对。

与一般 script 标签不同的是，对于原生 ESM 模块，浏览器提供了 modulepreload 来进行预加载:

<link rel="modulepreload" href="/src/app.js" />

modulepreload 的兼容性如下:

仅有 70% 左右的浏览器反对这个个性，不过在 Vite 中咱们能够通过配置一键开启 modulepreload 的 Polyfill，从而在使所有反对原生 ESM 的浏览器 (占比 90% 以上) 都能应用该个性，配置形式如下：

// vite.config.ts
export default {
  build: {polyfillModulePreload: true}
}

除了 Preload，Prefetch 也是一个比拟罕用的优化形式，它相当于通知浏览器闲暇的时候去预加载其它页面的资源，比方对于 A 页面中插入了这样的 link 标签：

<link rel="prefetch" href="https://B.com/index.js" as="script">

这样浏览器会在 A 页面加载结束之后去加载 B 这个域名下的资源，如果用户跳转到了 B 页面中，浏览器会间接应用预加载好的资源，从而晋升 B 页面的加载速度。而相比 Preload，Prefetch 的浏览器兼容性不太乐观，具体数据如下图所示。

二、资源优化

2.1 产物剖析报告

为了能可视化地感知到产物的体积状况，举荐大家用 rollup-plugin-visualizer 来进行产物剖析。装置好之后，就能够间接应用了，应用形式如下:

// 注: 首先须要装置 rollup-plugin-visualizer 依赖
import {defineConfig} from "vite";
import react from "@vitejs/plugin-react";
import {visualizer} from "rollup-plugin-visualizer";


// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react(),
    visualizer({
      // 打包实现后主动关上浏览器，显示产物体积报告
      open: true,
    }),
  ],
});

当你执行 npm run build 命令之后，浏览器会主动关上产物剖析页面，如下图。

从中你能够很不便地察看到产物体积的散布状况，进步排查问题的效率，比方定位到体积某些过大的包，而后针对性地进行优化。

2.2 资源压缩

在生产环境中，为了极致的代码体积，咱们个别会通过构建工具来对产物进行压缩。具体来说，有这样几类资源能够被压缩解决: JavaScript 代码、CSS 代码和图片文件。

2.2.1 JavaScript 压缩

在 Vite 生产环境构建的过程中，JavaScript 产物代码会主动进行压缩，相干的配置参数如下：

// vite.config.ts
export default {
  build: {
    // 类型: boolean | 'esbuild' | 'terser'
    // 默认为 `esbuild`
    minify: 'esbuild',
    // 产物指标环境
    target: 'modules',
    // 如果 minify 为 terser，能够通过上面的参数配置具体行为
    // https://terser.org/docs/api-reference#minify-options
    terserOptions: {}}
}

值得注意的是 target 参数，也就是压缩产物的指标环境。Vite 默认的参数是 modules，即如下的 browserlist：

['es2019', 'edge88', 'firefox78', 'chrome87', 'safari13.1']

可能你会有疑难，既然是压缩代码，为什么还跟指标环境有关系呢？其实，对于 JS 代码压缩的了解仅仅停留在去除空行、混同变量名的层面是不够的，为了达到极致的压缩成果，压缩器个别会依据浏览器的指标，会对代码进行语法层面的转换，比方上面这个例子:

// 业务代码中
info == null ? undefined : info.name

如果你将 target 配置为 exnext，也就是最新的 JS 语法，会发现压缩后的代码变成了上面这样：

info?.name

这就是压缩工具在背地所做的事件，将某些语句辨认之后转换成更高级的语法，从而达到更优的代码体积。因而，设置适合的 target 就显得特地重要了，一旦指标环境的设置不能笼罩所有的用户群体，那么极有可能在某些低端浏览器中呈现语法不兼容问题，从而产生线上事变。

2.2.2 CSS 压缩

对于 CSS 代码的压缩，Vite 中的相干配置如下：

// vite.config.ts
export default {
  build: {
    // 设置 CSS 的指标环境
    cssTarget: ''
  }
}

默认状况下 Vite 会应用 Esbuild 对 CSS 代码进行压缩，个别不须要咱们对 cssTarget 进行配置。不过在须要兼容安卓端微信的 WebView 时，咱们须要将 build.cssTarget 设置为 chrome61，以避免 vite 将 rgba() 色彩转化为 #RGBA 十六进制符号的模式，呈现款式问题。

2.2.3 图片压缩

图片资源是个别是产物体积的大头，如果能无效地压缩图片体积，那么对我的项目体积来说会失去不小的优化，而在 Vite 中咱们个别应用 vite-plugin-imagemin 来进行图片压缩。

2.2.4 产物拆包

一般来说，如果不对产物进行代码宰割(或者拆包)，全副打包到一个 chunk 中，会产生如下的问题：

  • 首屏加载的代码体积过大，即便是以后页面不须要的代码也会进行加载。
  • 线上缓存复用率极低，改变一行代码即可导致整个 bundle 产物缓存生效。

而 Vite 中内置如下的代码拆包能力：

  • CSS 代码宰割，即实现一个 chunk 对应一个 css 文件。
  • 默认有一套拆包策略，将利用的代码和第三方库的代码别离打包成两份产物，并对于动静 import 的模块独自打包成一个 chunk。

当然，咱们也能够通过 manualChunks 参数进行自定义配置。

// vite.config.ts
{
  build {
    rollupOptions: {
      output: {
        // 1. 对象配置
        manualChunks: {
          // 将 React 相干库打包成独自的 chunk 中
          'react-vendor': ['react', 'react-dom'],
          // 将 Lodash 库的代码独自打包
          'lodash': ['lodash-es'],
          // 将组件库的代码打包
          'library': ['antd'],
        },
        // 2. 函数配置
          if (id.includes('antd') || id.includes('@arco-design/web-react')) {return 'library';}
          if (id.includes('lodash')) {return 'lodash';}
          if (id.includes('react')) {return 'react';}
      },
    }
  },
}

当然，在函数配置中，咱们还须要留神循环援用的问题。

2.2.5 按需加载

在一个残缺的 Web 利用中，对于某些模块以后页面可能并不需要，如果浏览器在加载以后页面的同时也须要加载这些不必要的模块，那么可能会带来重大的性能问题。一个比拟好的形式是对路由组件进行动静引入，比方在 React 利用中应用 @loadable/component 进行组件异步加载。

import React from "react";
import ReactDOM from "react-dom";
import loadable from "@loadable/component";
import {BrowserRouter, Routes, Route} from "react-router-dom";


const Foo = loadable(() => import("./routes/Foo"));
const Bar = loadable(() => import("./routes/Bar"));


ReactDOM.render(
  <React.StrictMode>
    <BrowserRouter>
      <Routes>
        <Route path="/foo" element={<Foo />} />
        <Route path="/bar" element={<Bar />} />
      </Routes>
    </BrowserRouter>
  </React.StrictMode>,
  document.getElementById("root")
);

这样在生产环境中，Vite 也会将动静引入的组件独自打包成一个 chunk。当然，对于组件外部的逻辑，咱们也能够通过动静 import 的形式来提早执行，进一步优化首屏的加载性能，如下代码所示:

function App() {const computeFunc = async () => {
    // 提早加载第三方库
    // 须要留神 Tree Shaking 问题
    // 如果间接引入包名，无奈做到 Tree-Shaking，因而尽量导入具体的子门路
    const {default: merge} = await import("lodash-es/merge");
    const c = merge({a: 1}, {b: 2});
    console.log(c);
  };
  return (
    <div className="App">
      <p>
        <button type="button" onClick={computeFunc}>
          Click me
        </button>
      </p>
    </div>
  );
}


export default App;

三、预渲染优化

预渲染是当今比拟支流的优化伎俩，次要包含服务端渲染 (SSR) 和动态站点生成 (SSG) 这两种技术。

在 SSR 的场景下，服务端生成好残缺的 HTML 内容，间接返回给浏览器，浏览器可能依据 HTML 渲染出残缺的首屏内容，而不须要依赖 JS 的加载，从而升高浏览器的渲染压力；而另一方面，因为服务端的网络环境更优，能够更快地获取到页面所需的数据，也能节俭浏览器申请数据的工夫。

而 SSG 能够在构建阶段生成残缺的 HTML 内容，它与 SSR 最大的不同在于 HTML 的生成在构建阶段实现，而不是在服务器的运行时。SSG 同样能够给浏览器残缺的 HTML 内容，不依赖于 JS 的加载，能够无效进步页面加载性能。不过相比 SSR，SSG 的内容往往动态性不够，适宜比拟动态的站点，比方文档、博客等场景。

四、小结

本文次要围绕 Vite 我的项目的性能优化主题，从网络优化、资源优化及预渲染优化三个维度带你理解我的项目罕用的一些优化伎俩: 在网络优化层面，我给你介绍了 HTTP2、DNS 预解析、Preconenct、Preload 和 Prefetch 这些优化措施，在资源优化层面，介绍了构建产物剖析、资源压缩、产物拆包、按需加载等伎俩，最初，在预渲染优化方面，从新回顾了 SSR 和 SSG 的相干内容。

退出移动版