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，客户端渲染，顾名思义就是将所有的数据获取、页面渲染、事件绑定全部放在客户端浏览器去执行。

流程如下：

1. 客户端浏览器向服务端（Nest/Talos）发出请求
2. 服务端返回页面主文档index.html
3. 浏览器开始渲染index.html，此时的页面是白屏页面，并没有填充需要渲染的内容，会加载一些link、script和页面的bundle.js
4. 执行bundle.js，向后端服务请求数据、向CDN请求图片
5. 服务端返回数据、图片
6. 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