SSR改造方案

2022-07-03 本文已影响0人马建阳

一、背景

会员中心页面上线后，经过需求的不停迭代，页面的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层做了，高端机型的网络请求和渲染性能优势体现的就不明显了，而对低端机型来说反而变好了。

附压测数据：

https://km.sankuai.com/page/1290403143