nami性能优化指南
背景
组内性能指标优化目标
| 指标 | 说明 |
|---|---|
| FSP-tp90<=3000ms | 此项指标虽然包含所有维度的优化，但会更倾向于低端机型、弱网络场景下的优化 |
| 秒开率>=50%（相当于FSP-tp50<=1000ms） | 更倾向于对高端机型以及基于架构技术方案瓶颈的优化 |
目前Nami架构已支持的渲染方式
| 渲染方式 | 说明 |
|---|---|
| CSR(Client Side Rendering) | 客户端渲染 |
| PrefetchData&CSR | 服务端数据预取&客户端渲染 |
| SSR(Server Side Rendering) | 服务端渲染 |
| PrefetchData&SSR | 服务端数据预取&服务端渲染 |
| SSG(Static Site Generation) | 静态网站生成 |
渲染方式
由于我们每个项目的业务场景以及页面结构都存在着很大的差异，所以我们需要选择不同的渲染方案去优化每个页面的性能。那么首要的任务就是搞懂每种渲染方式都做了下什么，不然一切的优化动作的是听天由命。
1）CSR(Client Side Rendering)
CSR，客户端渲染，顾名思义就是将所有的数据获取、页面渲染、事件绑定全部放在客户端浏览器去执行。
流程如下：
- 客户端浏览器向服务端（Nest/Talos）发出请求
- 服务端返回页面主文档index.html
- 浏览器开始渲染index.html，此时的页面是白屏页面，并没有填充需要渲染的内容，会加载一些link、script和页面的bundle.js
- 执行bundle.js，向后端服务请求数据、向CDN请求图片
- 服务端返回数据、图片
- bundle.js使用请求回来的数据、图片资源完成页面渲染
优点：
- 目前Nami架构下，不需要任何改造，只需将page.config.js中useSSR设置为false
缺点：
- 将渲染逻辑、数据请求完全交给客户端去处理，完全依赖手机性能、当前网络质量，复杂的页面会很慢
2）PrefetchData&CSR
PrefetchData&CSR，就是将原本在客户端发起的初始数据请求放到服务端去进行，并且将获取的数据注入到页面主文档中一起返回给客户端。
流程与CSR大体相同，只是在API请求方面不同：
与纯CSR相比，仅多了2、3两步，这样一来，既可以发挥服务端内网请求的速度优势，又避免了客户端网络环境参差不齐带来的接口性能的不确定性。
优点：
-
内网请求速度更快，避免了客户端网络环境参差不齐带来的接口性能的不确定性
-
可以初始化数据(window.INITIAL_STATE)直接挂载到全局状态中，会对渲染性能有一定的提升
缺点：
- 由于服务端在返回主文档前会请求数据接口，会拖慢渲染服务整体的响应时间，所以要注意给初始化数据接口请求加上一个合适的超时时间，以免由于业务接口故障造成url请求长时间无响应
案例：
手机充值CSR+PrefetchData改造方案
3）PrefetchData&SSR
PrefetchData&SSR，就是在服务端进行初始数据的请求，由于服务端没有dom，所以会将数据写入组件并通过renderToString的方式渲染为html字符串，然后将渲染好的页面以及初始数据直接返回给客户端，到达客户端后还会进行一次hydration（水合），对页面进行修补并挂载事件等。
流程如下：
优点：
-
将数据获取和页面渲染的工作放在服务端，消除了客户端网络环境和设备性能带来的影响，直接返回给客户端渲染好的html页面以及挂载在window上的初始数据，用户可以更快看到完整页面，会带来更快的首屏渲染时间。
-
通过hydration水合的方式，实现服务端和客户端的共同渲染，在客户端对返回的页面进行数据和渲染的修补工作。
-
有利于SEO。
缺点：
-
将数据获取和页面渲染的工作放在服务端，会对服务器有一定的性能消耗，也会相对的拖慢渲染服务的响应时间。
-
由于会在客户端进行水合二次渲染，绑定一些事件，修补一些数据，所以会对TTI的时间点有一定的影响。
-
要对业务代码进行一些服务端的改造，例如window、document这些在node端没有的全局对象兼容。
案例：
会员中心SSR改造方案
4）SSG(Static Site Generation)
SSG，静态网站生成，此种渲染方式的页面渲染工作不是在请求时完成的，而是在项目构建阶段完成的，适用于无差异化的静态页面。
构建流程：
优点：
-
用户访问页面相当于访问静态资源，直接返回渲染好的页面，用户会直接看到完整页面，提升首屏渲染时间以及可交互时间。
-
由于构建阶段已经完成页面渲染，所以相当于静态资源，部署方式更加灵活，可以部署到渲染服务，也可以部署到CDN。
-
有利于SEO。
缺点：
-
对页面的业务逻辑要求相对严格，必须是千人一面的静态页面。
-
要对业务代码进行一些服务端的改造，例如window、document这些在node端没有的全局对象兼容。
案例：
会员中心规则页SSG改造
组内现有优化方案
| 方案 | 文档&示例 |
|---|---|
| 服务端数据预取(PrefetchData)，将获取页面初始数据的请求放在服务端完成 | 手机充值CSR+PrefetchData改造方案 |
| 服务端渲染(SSR)，将页面的部分渲染工作放在服务端完成 | 会员中心SSR改造方案 |
| 静态网站生成(SSG)，将无差异化的静态页面的渲染工作放在项目构建阶段，直接返回给客户端最终展示页面 | 会员中心规则页SSG改造 |
| 基于客户端设备像素比(window.devicePixelRatio)，加载不同倍数的图片资源 | 勋章页图片裁剪 |
| 将框架原有的渲染时动态polyfill引入方案改为在项目构架时注入统一polyfill | 取消服务端 polyfill 注入，使用 vite 生成 polyfill |
