背景

組內(nèi)性能指標(biāo)優(yōu)化目標(biāo)

目前Nami架構(gòu)已支持的渲染方式

渲染方式

由于我們每個(gè)項(xiàng)目的業(yè)務(wù)場(chǎng)景以及頁(yè)面結(jié)構(gòu)都存在著很大的差異，所以我們需要選擇不同的渲染方案去優(yōu)化每個(gè)頁(yè)面的性能。那么首要的任務(wù)就是搞懂每種渲染方式都做了下什么，不然一切的優(yōu)化動(dòng)作的是聽(tīng)天由命。

1）CSR(Client Side Rendering)

CSR，客戶端渲染，顧名思義就是將所有的數(shù)據(jù)獲取、頁(yè)面渲染、事件綁定全部放在客戶端瀏覽器去執(zhí)行。

流程如下：

1. 客戶端瀏覽器向服務(wù)端（Nest/Talos）發(fā)出請(qǐng)求
2. 服務(wù)端返回頁(yè)面主文檔index.html
3. 瀏覽器開(kāi)始渲染index.html，此時(shí)的頁(yè)面是白屏頁(yè)面，并沒(méi)有填充需要渲染的內(nèi)容，會(huì)加載一些link、script和頁(yè)面的bundle.js
4. 執(zhí)行bundle.js，向后端服務(wù)請(qǐng)求數(shù)據(jù)、向CDN請(qǐng)求圖片
5. 服務(wù)端返回?cái)?shù)據(jù)、圖片
6. bundle.js使用請(qǐng)求回來(lái)的數(shù)據(jù)、圖片資源完成頁(yè)面渲染

優(yōu)點(diǎn)：

• 目前Nami架構(gòu)下，不需要任何改造，只需將page.config.js中useSSR設(shè)置為false

缺點(diǎn)：

• 將渲染邏輯、數(shù)據(jù)請(qǐng)求完全交給客戶端去處理，完全依賴手機(jī)性能、當(dāng)前網(wǎng)絡(luò)質(zhì)量，復(fù)雜的頁(yè)面會(huì)很慢

2）PrefetchData&CSR

PrefetchData&CSR，就是將原本在客戶端發(fā)起的初始數(shù)據(jù)請(qǐng)求放到服務(wù)端去進(jìn)行，并且將獲取的數(shù)據(jù)注入到頁(yè)面主文檔中一起返回給客戶端。

流程與CSR大體相同，只是在API請(qǐng)求方面不同：

與純CSR相比，僅多了2、3兩步，這樣一來(lái)，既可以發(fā)揮服務(wù)端內(nèi)網(wǎng)請(qǐng)求的速度優(yōu)勢(shì)，又避免了客戶端網(wǎng)絡(luò)環(huán)境參差不齊帶來(lái)的接口性能的不確定性。

優(yōu)點(diǎn)：

• 內(nèi)網(wǎng)請(qǐng)求速度更快，避免了客戶端網(wǎng)絡(luò)環(huán)境參差不齊帶來(lái)的接口性能的不確定性

• 可以初始化數(shù)據(jù)(window.INITIAL_STATE)直接掛載到全局狀態(tài)中，會(huì)對(duì)渲染性能有一定的提升

缺點(diǎn)：

• 由于服務(wù)端在返回主文檔前會(huì)請(qǐng)求數(shù)據(jù)接口，會(huì)拖慢渲染服務(wù)整體的響應(yīng)時(shí)間，所以要注意給初始化數(shù)據(jù)接口請(qǐng)求加上一個(gè)合適的超時(shí)時(shí)間，以免由于業(yè)務(wù)接口故障造成url請(qǐng)求長(zhǎng)時(shí)間無(wú)響應(yīng)

案例：
手機(jī)充值CSR+PrefetchData改造方案

3）PrefetchData&SSR

PrefetchData&SSR，就是在服務(wù)端進(jìn)行初始數(shù)據(jù)的請(qǐng)求，由于服務(wù)端沒(méi)有dom，所以會(huì)將數(shù)據(jù)寫入組件并通過(guò)renderToString的方式渲染為html字符串，然后將渲染好的頁(yè)面以及初始數(shù)據(jù)直接返回給客戶端，到達(dá)客戶端后還會(huì)進(jìn)行一次hydration（水合），對(duì)頁(yè)面進(jìn)行修補(bǔ)并掛載事件等。

流程如下：

優(yōu)點(diǎn)：

• 將數(shù)據(jù)獲取和頁(yè)面渲染的工作放在服務(wù)端，消除了客戶端網(wǎng)絡(luò)環(huán)境和設(shè)備性能帶來(lái)的影響，直接返回給客戶端渲染好的html頁(yè)面以及掛載在window上的初始數(shù)據(jù)，用戶可以更快看到完整頁(yè)面，會(huì)帶來(lái)更快的首屏渲染時(shí)間。

• 通過(guò)hydration水合的方式，實(shí)現(xiàn)服務(wù)端和客戶端的共同渲染，在客戶端對(duì)返回的頁(yè)面進(jìn)行數(shù)據(jù)和渲染的修補(bǔ)工作。

• 有利于SEO。

缺點(diǎn)：

• 將數(shù)據(jù)獲取和頁(yè)面渲染的工作放在服務(wù)端，會(huì)對(duì)服務(wù)器有一定的性能消耗，也會(huì)相對(duì)的拖慢渲染服務(wù)的響應(yīng)時(shí)間。

• 由于會(huì)在客戶端進(jìn)行水合二次渲染，綁定一些事件，修補(bǔ)一些數(shù)據(jù)，所以會(huì)對(duì)TTI的時(shí)間點(diǎn)有一定的影響。

• 要對(duì)業(yè)務(wù)代碼進(jìn)行一些服務(wù)端的改造，例如window、document這些在node端沒(méi)有的全局對(duì)象兼容。

案例：
會(huì)員中心SSR改造方案

4）SSG(Static Site Generation)

SSG，靜態(tài)網(wǎng)站生成，此種渲染方式的頁(yè)面渲染工作不是在請(qǐng)求時(shí)完成的，而是在項(xiàng)目構(gòu)建階段完成的，適用于無(wú)差異化的靜態(tài)頁(yè)面。

構(gòu)建流程：

優(yōu)點(diǎn)：

• 用戶訪問(wèn)頁(yè)面相當(dāng)于訪問(wèn)靜態(tài)資源，直接返回渲染好的頁(yè)面，用戶會(huì)直接看到完整頁(yè)面，提升首屏渲染時(shí)間以及可交互時(shí)間。

• 由于構(gòu)建階段已經(jīng)完成頁(yè)面渲染，所以相當(dāng)于靜態(tài)資源，部署方式更加靈活，可以部署到渲染服務(wù)，也可以部署到CDN。

• 有利于SEO。

缺點(diǎn)：

• 對(duì)頁(yè)面的業(yè)務(wù)邏輯要求相對(duì)嚴(yán)格，必須是千人一面的靜態(tài)頁(yè)面。

• 要對(duì)業(yè)務(wù)代碼進(jìn)行一些服務(wù)端的改造，例如window、document這些在node端沒(méi)有的全局對(duì)象兼容。

案例：

會(huì)員中心規(guī)則頁(yè)SSG改造

組內(nèi)現(xiàn)有優(yōu)化方案