前端打包、编译和优化

打包

目前前端世界主流的前 3 名模块打包器仍然是 Webpack 、 Rollup 和 Esbuild 。

Webpack

本质上，Webpack 是一个用于现代 JavaScript 应用程序的静态模块打包工具。当 Webpack 处理应用程序时，它会在内部从一个或多个入口点构建一个 依赖图(dependency graph) ，然后将你项目中所需的每一个模块组合成一个或多个 bundles，它们均为静态资源，用于展示你的内容。

使用如下命令来安装：webpacknpm install webpack -g

安装完后，可以输入webpack -v 命令查看是否安装成功。

文档：https://webpack.docschina.org/concepts/

Esbuild

Esbuild 是一个用 Go 编写的模块打包工具。因为它大量利用了 Go 中并行的特性，所以 Esbuild 非常快。

• Esbuild 内部的算法经过精心设计，在可能的情况下它将饱和使用所有可用的 CPU 内核
• Esbuild 中的所有功能在开始编写时就充分考虑了性能

文档：https://esbuild.github.io/

Rollup

Rollup 是一个 JavaScript 模块打包工具，可以将多个小的代码片段编译为完整的库和应用。与传统的 CommonJS 和 AMD 这一类非标准化的解决方案不同，Rollup 使用的是 ES6 版本 Javascript 中的模块标准。

• 与 Webpack 相比快速且轻量级
• 支持 Tree Shaking

文档：https://www.rollupjs.com/

Parcel

Parcel 是一个众所周知的零配置 Web 应用程序打包器。

• 默认启用 Tree Shaking
• 使用 Rust 编写的 Javascript 编译器，以利用并行性并提高性能
• 支持原生 ES Moduls 和 CommonJS 两种模块标准
• 自动代码拆分

文档：https://parceljs.org/docs/

Turbopack

Turbopack 建立在 Turbo 之上：Turbo 是一种用于 Rust 的开源增量记忆框架。 Turbo 可以缓存程序中任何函数的结果。当程序被执行多次时，函数不会重新运行，除非它们的输入发生变化。

这种方法使 Turbopack 在计算增量更新方面非常快。这也优化了 Turbopack 使得开发过程中增量更新非常快，确保 dev server 能够快速响应代码变更。

Turbopack 还使用请求级编译方法来只编译请求的代码。如果浏览器请求某些 CSS，则只会编译该 CSS，而不编译引用的 images。采用请求级编译有助于减少请求数量并能够快速编译它们。

目前，Turbopack 比现有打包工具快 10 倍～700 倍。但它目前只可以在 Next.js v13 中使用。未来计划发布独立的 CLI、插件 API，并支持 Svelte 和 Vue 等其他框架。

文档：https://turbo.build/pack/docs

Nobundle：Vitejs

Vite 通过在一开始将应用中的模块区分为依赖和源码两类，改进了开发服务的启动时间。

• 依赖大多为在开发时不会变动的纯 JavaScript。一些较大的依赖（例如有上百个模块的组件库）处理的代价也很高。依赖也通常会存在多种模块化格式（例如 ESM 或者 CommonJS）。Vite 将会使用 esbuild (https://esbuild.github.io/) 预构建依赖(https://cn.vitejs.dev/guide/dep-pre-bundling.html)。
• 源码通常包含一些并非直接是 JavaScript 的文件，需要转换（例如 JSX，CSS 或者 Vue/Svelte 组件），时常会被编辑。同时并不是所有的源码都需要同时被加载（例如基于路由拆分的代码模块）。Vite 以 原生 ESM (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) 方式提供源码。这实际上是让浏览器接管了打包程序的部分工作：Vite 只需要在浏览器请求源码时进行转换并按需提供源码。根据情景动态导入代码，即只在当前屏幕上实际使用时才会被处理。

对于生产环境，Vitejs 使用 Rollup 进行打包。

文档：https://vitejs.cn/

编译工具

编译工具（Compiler）可以理解为将一种语言编写的源代码转换为另一种语言的过程。在前端开发过程中，我们经常遇到如下两类编译场景：

1. 将 TS 转换为 JS；
2. 将新版本 JS 语法转换为低版本浏览器支持的语法；

当前前端界的编译工具，如下四个占据了大部分市场：

Babel

最早开始出现 JS 编译工具之一，也是目前使用最多的 JS 编译工具。随着 Babel 的出现，前端开发者可以直接编写现代 JS 代码，同时又不失去对旧浏览器的支持。

简单来说，Babel 是一个工具链，主要用于将 ECMAScript 2015+ 版本的代码转换为向后兼容的 JavaScript 语法，以便能够运行在当前和旧版本的浏览器或其他环境中。Babel 可以做如下事情：

• 语法转换，比如 const、let、?. 、箭头函数等
• 最新 ES API 和 ES 实例/静态方法的 Polyfill，如 Promise、Array.prototype.includes 等。这部分主要通过第三方库来 polyfill，如 core-js (https://github.com/zloirock/core-js)
• 源码转换（codemods）

Babel 官方提供一个 在线编译网站(https://babeljs.io/repl)，大家可以使用它便捷的体验 Babel 的编译效果。

Babel 构建在插件之上，默认情况下，Babel 不做任何处理，需要借助插件来完成语法的解析、转换、输出。

TSC

TSC（TypeScript Compiler） 是 TS 语言官方的编译器，最初 TS 语言只能使用 TSC 进行编译，随着 Babel 等工具也相继支持编译 TS，你可能有疑问，他们之间有什么区别吗？答案是有的， 相对于 Babel，TSC 有如下 优势：

• 可以进行类型检查；
• 可以识别所有的类型并生成 .d.ts 类型文件；

原因在于 Babel 是单个文件编译的，不会解析其他文件的信息，而 TSC 的类型检查需要拿到整个工程的类型信息，需要做类型的引入、多文件 namespace 的合并等。而 Babel 编译 TS 只是去掉类型声明，保留原有 JS 功能。

通过配置 target 也可以让 TSC 编译出低版本浏览器支持的代码，但存在一些 缺点：

• 对一些新语法缺乏支持，如提案阶段的语法；
• 对于 ES API 和 ES 实例/静态方法无法解析，需要单独添加 polyfill ；

综上，现在的前端 TS 项目一般还是会使用 Babel 做编译，使用 TSC 做类型检查。

Babel for transpiling, TSC for types ：

(https://www.typescriptlang.org/docs/handbook/babel-with-typescript.html#handbook-content)

SWC

一款基于 Rust 语言开发的编译工具，它相对于 Babel 的优势就是编译速度非常快，在它的官网上，写着如下一句话。

SWC is 20x faster than Babel on a single thread and 70x faster on four cores.

SWC 的成功得益于 Rust 语言，这是一门高效、性能更好且内存安全的语言。随着 SWC 的崛起，很快它就被 Next.js 采用，进而取代 Babel 作为 JS 编译工具。

优缺点：

SWC 最大的优势就是编译速度快，另外在可扩展性、WASM 支持、社区和生态系统方面也是做的非常不错的。

但是，如果从 Babel 切换到 SWC，也有一些问题需要考量：

• 相对于 Babel ， SWC 的编译支持上有一些区别，参考 官方列表 (https://swc.rs/docs/migrating-from-babel) 可能会导致代码的浏览器支持度降低
• SWC 也有插件系统，但仍是实验性的，且开发插件要学习 Rust 和 WebAssembly，上手门槛明显很高

SWC 并不满足只是一个编译工具，未来或将支持如下能力：

• 编译工具，替代 Babel
• 打包器，替代 Webpack，目前正在建设中：swcpack (https://swc.rs/docs/usage/bundling)
• 类型检查器，替代 TSC
• 压缩器，替代 Terser

esbuild

esbuild 更多是作为打包工具被大众熟知，我们在打包工具章节也做了介绍。

其实 esbuild 也是支持编译能力的，且速度要比 Babel 快很多，但是它不兼容低版本浏览器，产物无法降级到 ES6 以下。esbuild 也原生支持编译 TS 语言，同样不支持类型检查，遗憾的是官方也没有计划去做这件事。

优化技术

1、LightHouse

通过LightHouse获取页面FCP (First Contentful Paint)和Speed Index指标，首屏加载FCP要尽量减少白页，Speed Index越快越好（最多4s内） 2、Frame Rate

通过Frame Rate 工具检测页面FPS，遇到轮播图动画等页面交互时应该尽量保证fps流畅，防止用户观看时出现卡顿闪烁等视觉体验 3、NetWork

通过瀑布图NetWork，直观的看到接口的响应速度，尽量缩短响应的速度，同时也能看到一个页面的接口请求数，减少同时并发的请求，把不重要的请求往后排序，来提升性能 4、Performance

通过Performance监听主线程性能，尽量减少DOM加载时间

参考：https://blog.csdn.net/m0_68324632/article/details/127487822

5、Tree Shaking

摇树优化Tree Shaking是Webpack里非常重要的优化措施，它的优化效果在Webpack 5中又得到了进一步的提升。Tree Shaking可以帮我们检测模块中没有使用到的代码块，并在Webpack打包时将没有用到的代码块移除掉，减小打包后的资源体积大小。它的名字也非常形象，通过摇晃树把树上干枯无用的叶子摇掉。

参考：https://zhuanlan.zhihu.com/p/467104092