天貓汽車商詳頁的SSR改造實(shí)踐

由于汽車業(yè)務(wù)的特殊性，天貓汽車基于 Rax 多頁應(yīng)用自建了商品詳情的 H5 頁面。自定義商詳承載了眾多業(yè)務(wù)能力和投放場景。隨著業(yè)務(wù)的發(fā)展和頁面承載內(nèi)容的增多，開始出現(xiàn)白屏?xí)r間太長等體驗(yàn)問題。

前端性能優(yōu)化算是個(gè)老生常談的問題，我們的頁面已經(jīng)做過首屏接口合并、圖片懶加載、骨架屏等體驗(yàn)優(yōu)化，想進(jìn)一步提升用戶體驗(yàn)就要從渲染機(jī)制和渲染容器入手了。從容器側(cè)看，淘寶端原生提供的 pha 容器提供的數(shù)據(jù)預(yù)請求、資源離線緩存等功能，可以有效提升手淘內(nèi)的 H5 頁面體驗(yàn)。但是其它渠道的端缺少類似容器能力，需要從渲染機(jī)制方向?qū)ふ页雎贰?/span>

SSR（Server Side Render）是相對于現(xiàn)有渲染機(jī)制CSR（Client Side Render）的一種渲染方案。在用戶通過客戶端（Client Side）請求頁面資源時(shí)，CSR 拿到是一份空文檔，再通過數(shù)據(jù)請求、執(zhí)行渲染腳本后生成文檔，最后展示給用戶。而 SSR 在請求后拿到的就是服務(wù)端（Server Side）經(jīng)過數(shù)據(jù)請求腳本渲染以后的完整文檔，由于它不強(qiáng)依賴客戶端的能力，具有更加穩(wěn)定的性能和較好的用戶體驗(yàn)。

為了提升淘寶外、特別是中低端機(jī)用戶的瀏覽體驗(yàn)，我們對自定義商詳進(jìn)行了 SSR 化探索，完成了 Rax 多頁應(yīng)用向 Rax 全棧應(yīng)用的改造，以下是我們的改造歷程。

代碼結(jié)構(gòu)

項(xiàng)目現(xiàn)在的 Rax 多頁應(yīng)用體系和目標(biāo)體系 Rax 全棧應(yīng)用都基于 Rax 框架，目錄結(jié)構(gòu)比較相似，全棧應(yīng)用在多頁應(yīng)用的基礎(chǔ)上增加了服務(wù)端渲染函數(shù)和FaaS相關(guān) 工程配置。Rax 多頁應(yīng)用的目錄如下：

├── src
│   ├── app.json                    # 路由及頁面配置
│   ├── components/                 # 自定義業(yè)務(wù)組件
│   ├── pages/                      # 頁面
├── build.json                      # 工程配置
├── package.json
└── tsconfig.json

Rax 全棧應(yīng)用目錄如下：

├── src
│   ├── apis                      # 函數(shù)源碼
│   │   ├── configuration.ts
│   │   ├── lambda/               # 接口
│   │   ├── render                # 渲染函數(shù)目錄                       
│   │   │   ├── home/             # 渲染函數(shù)，需與 pages 里的頁面名一一對應(yīng)       
│   │   │   └── ....../  
│   │   └── typings/              # 數(shù)據(jù)類型定義
│   ├── pages                     # 頁面      
│   │       ├── home/   
│   │       └── ....../   
│   ├── document/                 # 文檔結(jié)構(gòu)
│   ├── app.json                  # 路由及頁面配置
│   └── typings.d.ts
├── build.json                    # 工程配置
├── f.yml                         # 函數(shù)平臺配置
├── midway.config.ts.             # midway 配置，主要指定接口和渲染目錄
├── package.json
└── tsconfig.json

從目錄來看，承載頁面渲染的核心業(yè)務(wù)邏輯如 pages、components 都無須改動(dòng)。SSR 模式下，服務(wù)端返回的不再是空文檔，而是經(jīng)過一次渲染后的文檔框架，所以需要保持代碼在 Node 環(huán)境下可運(yùn)行。由于汽車商詳在 Rax 多頁應(yīng)用開發(fā)時(shí)沒有這種環(huán)境約束，因此對技改提出了環(huán)境模擬的需求，這點(diǎn)在后面會(huì)著重提到。

數(shù)據(jù)請求

CSR 模式下，進(jìn)入頁面后拉取主接口數(shù)據(jù)，執(zhí)行 js 完成頁面渲染。SSR 下，主接口數(shù)據(jù)需要在服務(wù)端獲得，完成服務(wù)側(cè)的文檔渲染。

客戶端得到的只是一個(gè)干文檔，需要再次執(zhí)行一遍 js 以激活文檔的事件監(jiān)聽、狀態(tài)傳遞等，成為可交互的頁面，這個(gè)過程也有一個(gè)形象的名稱，叫注水（hydrate）：

?請求流程的轉(zhuǎn)變

由于請求時(shí)機(jī)的改變，請求及其前后邏輯需要移至服務(wù)端執(zhí)行。

汽車商詳基于自建的一套端到端的渲染方案（XRoot）進(jìn)行接口設(shè)計(jì)和頁面渲染。接口數(shù)據(jù)中是組件集，包括各組件名稱和對應(yīng)組件需要的 props。我們封裝了一套 XRoot 組件，自動(dòng)執(zhí)行接口請求、數(shù)據(jù)注入、頁面渲染等工作。

在商詳首頁中，該接口請求的工作并不只是數(shù)據(jù)拉取與注入，還承擔(dān)了一系列請求前后的業(yè)務(wù)邏輯（如設(shè)置全局變量、容災(zāi)處理等）。對其中邏輯進(jìn)行抽象歸納，將業(yè)務(wù)邏輯聚合到 beforeRequest 和 afterResponse 中：

SSR 模式下，主接口請求在服務(wù)端執(zhí)行，其執(zhí)行邏輯為：

afterResponse 邏輯中有一部分是對數(shù)據(jù)本身的處理，留在服務(wù)端實(shí)現(xiàn)。另一部分是 UI 相關(guān)的，需要在客戶端 Hydrate 階段再次執(zhí)行。

?中間層網(wǎng)關(guān)的模擬實(shí)現(xiàn)

在阿里集團(tuán)內(nèi)，移動(dòng)端接口和后端的交互會(huì)經(jīng)過了一層 MTOP 網(wǎng)關(guān)。MTOP 網(wǎng)關(guān)提供了協(xié)議解析、安全防護(hù)、穩(wěn)定性保障等能力。SSR 模式下，服務(wù)端的數(shù)據(jù)請求無法經(jīng)過這層網(wǎng)關(guān)，而是直接訪問后端 API。

此時(shí)業(yè)務(wù)依賴到的相關(guān) MTOP 能力需要業(yè)務(wù)側(cè)在 SSR 下手動(dòng)補(bǔ)齊，其中直接影響頁面渲染的就是 MTOP 對接口中空數(shù)據(jù)的處理：

原始接口數(shù)據(jù)中值為 null 的屬性都被 MTOP 層處理過了，如果 SSR 不做空值屬性的刪除，前端的默認(rèn)取值就會(huì)出問題：

const { text, tip = '默認(rèn)提示' } = tagsList[0];
console.log(tip); // 非空處理前：null ；非空處理后：'默認(rèn)提示'

這里寫一個(gè)簡單的工具函數(shù)來做這件事：

export const deleteNullProperties = (obj: Object | Array) => {
  const memory = new Set();
  const fn = (obj) => {
    if (memory.has(obj)) return obj;
    if (['[object Object]', '[object Array]'].includes(Object.prototype.toString.call(obj))) {
      for (const [key, value] of Object.entries(obj)) {
        if (value === null) {
          delete obj[key];
        } else {
          obj[key] = fn(value);
        }
      }
    }
    memory.add(obj);
    return obj;
  }
  return fn(obj);
}

?

另外，MTOP 網(wǎng)關(guān)還提供了用戶登陸態(tài)的解析與傳遞，SSR 側(cè)也需要業(yè)務(wù)自行從 cookie 中讀取用戶登陸信息。

環(huán)境模擬

一般來說，由于服務(wù)端和瀏覽器端環(huán)境的差異，在做前后端同構(gòu)應(yīng)用的時(shí)候，開發(fā)者都會(huì)自覺注意環(huán)境差異，避免在不恰當(dāng)?shù)臅r(shí)機(jī)訪問瀏覽器對象，導(dǎo)致 SSR 側(cè)報(bào)錯(cuò)。

但是由于本次是改造項(xiàng)目，歷史項(xiàng)目只關(guān)注 CSR 場景，不可避免地充斥著預(yù)期以外的 DOM/BOM 訪問，此時(shí)有以下幾種解決方案：

從改造成本和維護(hù)成本來看，借助框架能力和引入社區(qū)方案是兩種可以低成本探索的思路。

?框架能力

Rax 全棧應(yīng)用框架本身提供了在服務(wù)器端模擬瀏覽器環(huán)境的能力，從而來盡可能保證 SSR 和 CSR 編碼的一致性。其環(huán)境變量模擬的基本原則是：

1. 所模擬的信息可由服務(wù)端數(shù)據(jù)推導(dǎo)得出，例如 location、navigator。

2. 所模擬的信息不會(huì)引起代碼執(zhí)行邏輯的錯(cuò)誤，例如對 localStorage 的模擬。

從中可以看出，框架模擬能力并不旨在進(jìn)行環(huán)境模擬，相反它還在試圖為頁面提供一些真實(shí)有用的信息。因此框架提供的模擬能力相對有限，一些常用方法也沒有空方法占位，如試圖調(diào)用 window.addEventListener 時(shí)會(huì)報(bào) undefined 錯(cuò)誤。

由于 Hydrate 階段的存在，我們的目的只是希望代碼能夠在服務(wù)端不報(bào)錯(cuò)，客戶端側(cè)的二次渲染會(huì)提供更加準(zhǔn)確的信息，框架能力并不能滿足需要。

?jsdom-來自社區(qū)的服務(wù)端環(huán)境庫

jsdom 是許多 Web 標(biāo)準(zhǔn)的純 JavaScript 實(shí)現(xiàn)，特別是 WHATWG DOM和HTML標(biāo)準(zhǔn)。該項(xiàng)目并不是為了模擬服務(wù)端環(huán)境而存在，它的主要目標(biāo)是模擬足夠多的 Web 瀏覽器子集，使得頁面可以在服務(wù)端運(yùn)行，從而測試和抓取真實(shí)世界的 Web 應(yīng)用程序。 ?它對瀏覽器環(huán)境強(qiáng)大的模擬能力可以幫助我們避免對項(xiàng)目源碼的改造。 由于 jsdom 同樣追求對功能性的模擬，功能強(qiáng)大的同時(shí)，在服務(wù)端運(yùn)行時(shí)可能出現(xiàn)預(yù)料之外的問題，需要詳盡測試。在使用 jsdom 時(shí)，也遇到了一些版本兼容問題，可以通過降低庫版本和動(dòng)態(tài)加載等方式解決。

其他問題

?降級策略

Rax 全棧應(yīng)用框架采取中間件降級策略，SSR 側(cè)有任何報(bào)錯(cuò)都會(huì)自動(dòng)將空文檔返回給客戶端，由客戶端發(fā)起數(shù)據(jù)請求和渲染，即降級為 CSR。

降級邏輯

降級中間件源碼

業(yè)務(wù)側(cè)也可以根據(jù)需要使用框架提供的 useCSRRenderer 鉤子函數(shù)進(jìn)行主動(dòng)降級：

?自閉合標(biāo)簽問題

習(xí)慣了 react 的 JSX 語法體系，我們通常會(huì)寫出許多自閉合標(biāo)簽以提高可讀性和代碼整潔性：

// 自定義組件的自閉合



// 原生標(biāo)簽的自閉合

但事實(shí)上 HTML 規(guī)范并不支持對

，導(dǎo)致文檔結(jié)構(gòu)發(fā)生了變化：

為什么在 JSX 中寫自閉合標(biāo)簽?zāi)軌虻玫狡诖械慕Y(jié)果呢？事實(shí)上是 CSR 框架側(cè)幫我們做了這件事，如 react 在其官方文檔里就有提到：react地址：https://react-cn.github.io/react/tips/self-closing-tag.html

從實(shí)踐來看，Rax 框架在 CSR 側(cè)的渲染同樣做了類似的處理，但是 Rax 全棧應(yīng)用的服務(wù)端渲染沒有，其 SSR 側(cè)生成的文檔只是簡單將自閉合標(biāo)簽原樣返回：

不同階段下的文檔結(jié)構(gòu)

由于在 hydrate 階段瀏覽器判斷 ssr 文檔與客戶端預(yù)期不一致時(shí)，會(huì)被丟棄掉重新渲染，所以這種處理沒什么功能性問題。只是這樣就失去了 SSR 的首屏優(yōu)化功能。在 Rax 團(tuán)隊(duì)完善自閉合標(biāo)簽問題之前，業(yè)務(wù)側(cè)需要避免寫出非自定義標(biāo)簽的自閉合。

?與 CSR 倉庫的功能同步

因?yàn)槲覀兪菍?CSR 項(xiàng)目的改造，為了不影響線上功能，另啟了一個(gè)應(yīng)用倉庫。隨著改造的進(jìn)行，原 CSR 項(xiàng)目也一直在接新需求不停迭代。 借助 git merge --allow-unrelated-histories 機(jī)制，我們在代碼同步方面不必投入太多成本。但是為一個(gè)業(yè)務(wù)場景維護(hù)兩套應(yīng)用，其中需要付出的溝通、維護(hù)、測試等成本還是很高。

?下一步計(jì)劃

如前所述，兩個(gè)應(yīng)用的維護(hù)成本較高。因?yàn)閮烧叩目蚣芑A(chǔ)是一致的，我們就希望將兩個(gè)應(yīng)用合并起來，至少能降低一點(diǎn)代碼同步和溝通成本。與技術(shù)支持同學(xué)溝通了一下，發(fā)現(xiàn)沒有這個(gè)先例，可能會(huì)有很多意料之外的問題，所以這部分仍在試錯(cuò)中。

小結(jié)

借著本次服務(wù)端渲染（SSR）改造升級的實(shí)踐，我對前端的渲染機(jī)制也有了更深入的理解。雖然 SSR 相較于 CSR 有著許多優(yōu)勢，卻未成為 Web 渲染的主流模式，是因?yàn)闃?gòu)建 SSR 應(yīng)用并不輕松：需要熟悉服務(wù)端開發(fā)、了解服務(wù)端和客戶端的環(huán)境差異、服務(wù)部署、服務(wù)器運(yùn)維等，對前端開發(fā)提出了更高的要求。

而云原生基礎(chǔ)設(shè)施的蓬勃發(fā)展、Nodejs FaaS 函數(shù)服務(wù)建設(shè)的逐漸完善，都將大大降低 SSR 應(yīng)用的接入門檻。前端開發(fā)者將只需關(guān)注業(yè)務(wù)邏輯就能輕松獲得 SSR 能力，用戶也更有機(jī)會(huì)得到更好的交互體驗(yàn)。

審核編輯 ：李倩