[RFC] 068 - 首屏性能优化

[arvinxx]

背景

优化首屏加载性能

思路

基于 3b6432 commit （2024.11.03）的分析：

Route (app)                                   Size     First Load JS
┌ ƒ /                                         9.44 kB         447 kB
├ ƒ /_not-found                               171 B           105 kB
├ ƒ /(.)settings/modal                        5.22 kB         141 kB
├ ƒ /api/auth/[...nextauth]                   0 B                0 B
├ ƒ /api/auth/error                           1.23 kB         106 kB
├ ƒ /api/webhooks/casdoor                     0 B                0 B
├ ƒ /api/webhooks/clerk                       0 B                0 B
├ ƒ /api/webhooks/logto                       0 B                0 B
├ ƒ /chat                                     17.3 kB         676 kB

其中首屏 First Load JS 来到了 447 kb，这个应该是导致首屏加载比较慢的关键因素，看看可以怎么优化。

首先通过 npm run build:analyze 用 Webpack 来分析下构建产物：

将base path 选成 app/page 就可以将入口设定为 / 路径：

产物预览如下：

可以看到首屏中有几个比较大体积的chunk （尺寸都按 gzip 来评估）：

• 40604 (103kb): 包含dexie / i18next / mdast-util-from-markdown 等模块
• 92880（75kb）：包含antd modal 、rc-form 等组件；
• 66965（30kb）：包含 @ant-design/cssinjs 等基础依赖;
• 73766（28kb）： src/config/modelProviders 供应商配置文件；
• 48945（16kb）： client db、 user store 等业务代码；
• 57118 （13.32kb） zod 模块；
• 555（7.68kb）： ua-parser 模块；
• ...

剩余比较小的模块就不列了，上述列下来的总体积大致已经有 270+kb ，如果优化上述部分的 chunk 尺寸，理论上应该能提升一波首屏加载速度。

---

上述核心 chunk 中，一眼看过去并不需要的依赖有：

• dexie.mini.js 、mdast-util-from-markdown（在 server db 下理论上就不应该加载）
• config/modelProviders（首屏不需要）
• antd 的基础组件（首屏也不需要）

这些是首屏不需要的，但都直接被引入，所以如果能将这些依赖在首屏加载时移除，那么应该能较大程度地提升加载速度。

[BrandonStudio]

还有一点，很多ts文件只用到注释的类型也用import导入了，如果全部改成 import type 会不会有帮助？

[arvinxx]

这个不会，type 在 webpack 构建过程中会自动移除的，对包体积没有太大影响

[arvinxx]

Dexie 和 YJS 优化

经过 #4641 的优化，server db 模式下的首屏体积来到 362kb ，

Route (app)                                   Size     First Load JS
┌ ƒ /                                         9.27 kB         362 kB
├ ƒ /_not-found                               171 B           105 kB
├ ƒ /(.)settings/modal                        5.22 kB         142 kB
├ ƒ /api/auth/[...nextauth]                   0 B                0 B
├ ƒ /api/auth/error                           1.23 kB         106 kB
├ ƒ /api/webhooks/casdoor                     0 B                0 B
├ ƒ /api/webhooks/clerk                       0 B                0 B
├ ƒ /api/webhooks/logto                       0 B                0 B
├ ƒ /chat                                     17.2 kB         590 kB

从上图中可以看到 dexie 和 yjs 相关的依赖已经没了，带来了 82kb 的体积下降。

[arvinxx]

ModelProvider 优化

在 store 层做了引入关系分析，

发现引入 modelProviders 大对象的原因在于 modelList slice 依赖了 ModelProvider的配置文件，并且甚至是 ModelListState 所必须的初始状态。

这意味着如果仍然采取 useUserStore 的方式将无法实现该优化，因此需要将 model provider 部分的逻辑从 user Store 中移出来，单独变成一个 store。

PS: model provider 现在放在 userStore 的原因是这部分实现之前在 globalStore 中，当时从单用户迁移到多用户时，直接将 globalStore 中涉及到用户配置的逻辑全部挪到了 userStore 中，并且保持至今。

---

因此这部分的优化方案就比较清晰了：将 modelList slice 从 userStore 中剥离，独立变成 modelManageStore ，后续专门放置关于模型管理相关的功能逻辑实现。

[arvinxx]

antd 相关依赖优化

一开始试了直接注释 loading.tsx 的 Client 和 Redirect 组件，发现体积就降下来了，antd 相关的依赖也就没了。这表明 antd 的组件依赖引入来自 Client/Redirect。但分别注释后仍然发现存在 antd 相关依赖。但事实上 Client 和 Redirect 组件并没有直接引用 modal、message 等组件，是更上游的依赖方（例如 @lobehub/ui 或者 antd-style）引入的。

于是开了一个空仓库（https://github.com/lobehub/lobe-next-perf ）来测试对比：

建了 /page.tsx 和 /reference/page.tsx 作为参照，打包后产物如下：

Route (app)                              Size     First Load JS
┌ ○ /                                    4.88 kB         193 kB
├ ○ /_not-found                          872 B          88.1 kB
└ ○ /reference                           250 B          87.4 kB
+ First Load JS shared by all            87.2 kB
  ├ chunks/86cc20f5-0ac73bd9d0e45d71.js  53.6 kB
  ├ chunks/879-58c58cbc05f0239f.js       31.6 kB
  └ other shared chunks (total)          1.96 kB


○  (Static)  prerendered as static content

可以看到 / 比 /reference 大了 100k 左右，看下具体的产物分析 breakdown：

/reference 页面	/ 页面

可以看到其中 message/modal/notification 组件都引入了，正是这三个组件和相关的依赖，带来了近 100k 的尺寸。所以需要针对性做优化。