共计 1283 个字符，预计需要花费 4 分钟才能阅读完成。
大家好，我卡颂。
昨天在开源圈产生个小插曲。起因是有个用户示意：React新文档在文档构造、好看度、性能等各方面都达到很高的规范。
尤雨溪对 Vue 新文档与 React Beta 文档做了测试后示意：在性能这块，Vue新文档更具劣势。
Dan示意：以后文档还处于 Beta 版本，当初有更重要的工作要实现，正式版上线前会优化性能。
话虽这么说，Dan应该是通了个宵优化了一把性能：
本篇文章咱们来看看，Dan都做了哪些优化。
欢送退出人类高质量前端框架群，带飞
优化成果
通过优化后的 lightHouse 跑分：
作为对照，Vue文档的跑分：
两者 10 次 TTI 跑分比照：
这里的 TTI（Time to Interactive，即可交互工夫），掂量的是 页面变得齐全可交互所需工夫 ，其中 齐全可交互 指：
- 页面展现了 有用信息（由 FCP 掂量，FCP 指 First Contentful Paint）
- 可见页面中大部分元素实现事件绑定，交互响应的提早在 50ms 内
优化措施
优化次要有两个思路：
- 编译时：缩小打包体积
- 运行时：非首屏必须 代码提早加载
编译时优化
之前入口处全量引入了一个工具函数 utils，当初将其中办法拆分成不同文件，这样能缩小 首屏 bundle体积：
再比方：
这部分优化让 bundle 体积缩小约一半：
其次，以后 Next.js（文档应用的框架）没有默认开启 针对古代浏览器编译 。这意味着bundle 中会引入更多polyfill，有更多语法转换及帮忙函数。
Dan通过配置开启了这个性能：
运行时优化
运行时优化的形式次要是：懒加载非必须资源。
新文档中存在很多codesandbox(在线示例)，这些示例依赖CodeMirror linter，但这不是首屏必须的。
所以 Dan 将这部分资源懒加载：
除此之外，如果你仔细察看会发现，Total Blocking Time指标降落很多：
TBT（Total Blocking Time，即总阻塞工夫）测量页面 被阻止响应用户输出（例如鼠标点击、屏幕点击或按下键盘）的总工夫。
一般来说，如果 JS 执行工夫过长，就会影响这个指标。
咱们晓得，页面加载后前端框架会有 首屏渲染 的初始化过程。即便是服务端渲染，也会有Hydrate（注水）的过程。
而 React18 的Selective Hydration为解决这一问题提供了好办法。
如果你的 React18 利用是 SSR，那么被<Suspense/> 包裹的组件局部不会参加首次 Hydrate 的过程。
也就是说，被 <Suspense/> 包裹的局部不会影响阻塞工夫。
所以，尽管这部分工作很重要，但 Dan 须要做的，仅仅是把一些 对首屏显示不太重要的组件 包裹在 <Suspense/> 中。
能够看到，在将一些组件用 <Suspense/> 包裹前 Hydrate 作为一个长工作的耗时：
当包裹之后，这个长工作持续时间显著升高，进而升高TBT：
总结
这些只是初步的优化后果，后续还有很多优化工作值得去做。比方 INP（Interaction to Next Paint，与下一次 Paint 的交互）指标还是偏高：
Dan坦言：指标偏高的起因可能是因为 —— React自身比较慢。
他对此提出了一些猜测，你能够到这里参加探讨。