一、背景
会员中心页面上线后，经过需求的不停迭代，页面的fsp和秒开率表现的并不理想，还有不少提升的空间。基于此，需要做一些性能优化来进行改造。
针对其中的勋章首页页面的特点（偏静态的内容展示场景），非常适合在该页使用SSR进行优化改造。同时勋章页面低端机型的性能表现明显差于高端机型，通过服务端渲染，可以抹平手机网络请求和渲染性能造成的差距，有效的提升低端机型的性能表现。
勋章首页：偏静态的内容展示场景
机型性能表现差别：
机型网络请求差别：
二、技术方案
SSR简介
SSR(Server Side Rendering): 服务端渲染
React的 SSR :
• 也叫同构，是服务端渲染与客户端渲染的一个整合
• 它是在不改变前端开发方式的情况下实现服务端渲染的
• 用来解决纯客户端渲染带来的⾸屏渲染慢、SEO不友好的问题
SSR和CSR的对比
csr模式：
ssr模式：
从图中可以看出SSR 渲染的大致过程是：请求 Node 服务 -> Node 服务请求后端接口 -> Node 服务获取数据后渲染首屏HTML -> 浏览器解析 HTML -> 加载静态资源（CSS/JS）-> 渲染首屏。
可以看到 SSR 相比于 CSR，将首屏接口请求与渲染移到计算能力更强的服务端。
从时序上看，SSR 不需要加载 JS 文件，即可完成首屏呈现；
从接口请求的环境来看，SSR 请求页面的数据和首屏 HTML 的渲染是在服务端进行的，相对于 CSR，在接口请求上，尤其是首屏依赖多个接口时，具有内网/专线的可靠、低时延优势，可极大降低客户端网络环境不确定性和不稳定性所造成的网络耗时。
SSR使用场景
适⽤场景
• 需要在浏览器上做 SEO
• 已经有⼀个运行中的 React 应用，需要最佳的性能并愿意为增加的服务器资源付费
• 数据展示型⻚⾯
不适⽤场景
• 不需要做SEO
• 资源短缺(服务器or开发⼈员)
• ⻚⾯需要大量计算(包含大量图表)
三、项目中的核心实现
- 通过 getSSRData获取到数据,并使用store方法将数据直接更改，之后进行服务端渲染。
const getSSRData = async (ctx: Context): Store => {
const { medalStore } = stores
const medalService = new MedalService()
const { token, uuid, userid } = ctx.query
try {
const res = await medalService.getMedals(ctx, {
headers: { token },
params: {
userid,
uuid,
},
})
if (res?.data) {
const {
recentMedals = [],
} = res?.data
medalStore.setRecentMedals(recentMedals)
medalStore.setIsSsrData(true)
}
} catch (e) {
console.log(e)
}
return medalStore
}
const serverEntry =
(App: () => JSX.Element, callback?: Function): TRender =>
async (url: string, ctx?: Context) => {
enableStaticRendering(true)
const stores = callback ? await callback(ctx) : undefined
return {
html: ReactDOMServer.renderToString(
<Provider {...stores}>
<App />
</Provider>
),
data: stores,
}
}
export const render = serverEntry(App, getSSRData)
备注：renderToString
• 将 React Component 转化为 HTML 字符串
• 生成的 HTML 的 DOM 会带有额外属性（最外层 DOM 会有 data-reactroot 属性）
2. 前端合并store，并进行水合操作
export const clientEntry = (App: () => JSX.Element, Store?: Store): void => {
const initialStores = window.__INITIAL_STATE__ ?? {}
const mergeMedalStore = Object.assign(stores.medalStore, initialStores.medalStore)
const hydrateDOM = (
<Provider medalStore={mergeMedalStore}>
<App />
</Provider>
)
ReactDOM.hydrate(hydrateDOM, document.getElementById('app'))
}
clientEntry(App)
备注： ReactDOM.hydrate
• 将事件监听器器挂载到现有的 DOM 元素，而不是挂载整个 DOM
• 会修复客户端渲染与服务端渲染中的部分不一致的场景
-
标签不一致，直接使⽤用客户端渲染结果
-
⽂本内容不⼀致，替换文本内容
-
不修复属性不一致的情况
四、收益
整体
整体来看，勋章页的秒开率从39%到了52%，提升了13%。首屏时间从2.7s到了2.9s，提升了200ms。
可以看到SSR明显提升了秒开率，但是对于fsp并没有相应的提升。
为啥呢？
React SSR 与 CSR ⾸屏渲染时间对⽐
-
Time To First Byte(TTFB): ⾸字节时间，用于衡量⽹络和服务器响应性能
-
First Meaningful Paint(FMP):⻚面主要内容出现在屏幕上的时间点
-
Time To Interactive (TTI):布局已趋于稳定、关键的⽹网络字体可⻅见、主要线程⾜以处理⽤户输入的时间点
从图中可以看出SSR相比CSR的首屏时间是不一定会变好的。
所以整体效果算是符合预期的。
不同机型的表现分析
17和18号的数据
22和23号的数据
从数据中可以看到低端机型的秒开率由于ssr的改造，提升特别明显。印证了之前说过的通过服务端渲染，可以抹平手机网络请求和渲染性能造成的差距，有效的提升低端机型的性能表现。
而fsp（tp90）在高端机型上表现的反而差了，对低端机型的表现是提升的。这也可以理解。由于渲染主要放在node层做了，高端机型的网络请求和渲染性能优势体现的就不明显了，而对低端机型来说反而变好了。
附压测数据：
网友评论