有研究發(fā)現(xiàn)，網(wǎng)站加載時(shí)間每增加一秒，用戶便會(huì)流失 10%。為提高頁(yè)面的秒開(kāi)率，各路人馬不斷探索著優(yōu)化策略，僅僅在瀏覽器領(lǐng)域下的優(yōu)化已經(jīng)滿足不了極致的要求了，大家開(kāi)始往服務(wù)端方向不斷探索，并一度讓【服務(wù)端渲染】這一古早的概念 “翻紅”，且炒得火熱。

服務(wù)端渲染簡(jiǎn)稱 SSR，全稱 Server Side Rendering，顧名思義是將渲染的工作放在 Server 端進(jìn)行。這種辦法不僅有利于首屏渲染，提高 SPA 應(yīng)用的首屏響應(yīng)速度，還方便搜索引擎抓取，有利于 SEO 優(yōu)化。不過(guò)，到 2023 年了，SSR 并沒(méi)有預(yù)想中的流行。

有評(píng)論認(rèn)為，大部分用 SSR 的原因是為了服務(wù) SEO，但現(xiàn)在搜索引擎已經(jīng)跟上發(fā)展步伐了，對(duì)于用框架寫(xiě)成的 SPA 支持也不錯(cuò)，所以 SSR 必要性沒(méi)那么大了。還有人覺(jué)得 SSR 就是偽需求，業(yè)務(wù)邏輯和控制器分離好了加載一樣快。

但也有評(píng)論認(rèn)為，現(xiàn)在仍然有大量的用戶因?yàn)?a target="_blank">網(wǎng)絡(luò)環(huán)境或設(shè)備情況，在訪問(wèn) Web 頁(yè)面的時(shí)候無(wú)法達(dá)到很好的體驗(yàn)，如果要提升這部分用戶的體驗(yàn)，那么 SSR 就是一種不可或缺的方式。

對(duì)此，真實(shí)的情況是怎樣的？實(shí)際應(yīng)用中，阻礙 SSR 成為 Web 主流開(kāi)發(fā)模式的原因是什么？這種方法放到今天的環(huán)境下過(guò)時(shí)了嗎？什么樣的業(yè)務(wù)場(chǎng)景更適合 SSR 呢？對(duì)此，開(kāi)源中國(guó)邀請(qǐng)了兩位前端大佬，來(lái)聽(tīng)聽(tīng)他們的看法。

劉奎，社區(qū)昵稱 kuitos 。支付寶體驗(yàn)技術(shù)部前端工程師，開(kāi)源微前端方案 qiankun 作者，目前在螞蟻負(fù)責(zé) Web 基建研發(fā)相關(guān)工作。

劉勇，社區(qū)昵稱天豬，某大廠 Node.js Infra 負(fù)責(zé)人，EggJS / CNPM 核心開(kāi)發(fā)者。

SSR，并不是偽需求

Q1：以你的經(jīng)驗(yàn)，什么類型的項(xiàng)目和場(chǎng)景更常用 SSR ？能舉些例子嗎？

劉奎：對(duì)首屏性能非常敏感，或者對(duì) SEO 有強(qiáng)訴求的這類網(wǎng)站會(huì)更常用 SSR，如：

電商平臺(tái)：更快的首屏渲染可以讓用戶更快的看到商品信息，提升購(gòu)買轉(zhuǎn)化率

營(yíng)銷活動(dòng)頁(yè)：秒開(kāi)能有效提升營(yíng)銷活動(dòng)的業(yè)務(wù)效果

門戶網(wǎng)站：內(nèi)容型站點(diǎn)通常對(duì) SEO 有著比較強(qiáng)的訴求

Q2：從你的實(shí)際體驗(yàn)出發(fā)，你覺(jué)得 SSR 相比于 CSR（Client-side rendering）模式，優(yōu)勢(shì)在哪？

劉奎：從我個(gè)人體驗(yàn)來(lái)看，最大的優(yōu)勢(shì)還是在首屏體驗(yàn)上，SSR 模式下 HTML 加載過(guò)程中用戶就能看到有效的頁(yè)面內(nèi)容，這個(gè)基本是 CSR 很難做到的。

Q3：如今搜索引擎已經(jīng)支持渲染了，你認(rèn)為還有必要因?yàn)?SEO 的原因使用 SSR 嗎？

劉奎：由于眾所周知的原因，國(guó)內(nèi)的搜索引擎對(duì) SPA 類型的應(yīng)用支持的并不好，如果希望自己的網(wǎng)站能更好的被爬蟲(chóng)索引到，基本上還是需要使用 SSR（或者 SSR 的變種）方案了。

Q4：有人認(rèn)為 SSR 是偽需求，要改善首屏渲染性能的話，后端服務(wù)的業(yè)務(wù)邏輯和控制器分離，控制器分視圖控制器和接口控制器，調(diào)用相同的業(yè)務(wù)邏輯。第一次打開(kāi)頁(yè)面，前端 JavaScript 加載頁(yè)面渲染的數(shù)據(jù)，用戶交互時(shí)再請(qǐng)求接口獲取數(shù)據(jù)。這個(gè)方案比性能著急的 SSR 強(qiáng)多了。你怎么評(píng)價(jià)？

劉奎：這個(gè)方案本質(zhì)還是 CSR，無(wú)法解決 CSR 方案原生的問(wèn)題：即用戶必須等到 JS 下載完成 -》 發(fā)起接口請(qǐng)求 -》 JS 獲取數(shù)據(jù)渲染頁(yè)面之后，才能看到有效內(nèi)容的問(wèn)題。在越苛刻的網(wǎng)絡(luò)環(huán)境及用戶設(shè)備條件下，這個(gè)問(wèn)題會(huì)越明顯。

劉勇：根據(jù)團(tuán)隊(duì)的基建成熟度和業(yè)務(wù)場(chǎng)景做技術(shù)選型，這 2 個(gè)方案沒(méi)有絕對(duì)的優(yōu)劣，也不是絕對(duì)的割裂，它們是可以通過(guò)前端工程化結(jié)合成一個(gè)方案的。

SSR，想紅有點(diǎn)難 Q5：以當(dāng)前的形勢(shì)來(lái)看，SSR 并沒(méi)能成為 Web 主流的開(kāi)發(fā)模式，你覺(jué)得這其中的阻礙有哪些？

劉奎：我覺(jué)得主要有這幾類原因：

技術(shù)復(fù)雜度：SSR 需要在服務(wù)器端進(jìn)行渲染，并與前端框架進(jìn)行集成，對(duì)開(kāi)發(fā)人員來(lái)說(shuō)需要掌握更多的技術(shù)知識(shí)。

SSR 帶來(lái)的額外的開(kāi)發(fā)及維護(hù)成本：相對(duì)于 CSR，SSR 方案需要前端額外去關(guān)注服務(wù)端相關(guān)的開(kāi)發(fā)及運(yùn)維，比如如何寫(xiě)出更高性能的服務(wù)端渲染邏輯，如何處理潛在的內(nèi)存泄露、變量污染等隔離問(wèn)題，如何做 SSR 的容災(zāi)（在 SSR 失敗時(shí) fallback 到 CSR）等，這些都需要團(tuán)隊(duì)有額外的資源及時(shí)間投入。

場(chǎng)景匹配度：國(guó)內(nèi)大量的服務(wù)是通過(guò)小程序、APP 這類載體進(jìn)行分發(fā)的，純 Web 技術(shù)棧的產(chǎn)品相對(duì)較少，這點(diǎn)與國(guó)外的場(chǎng)景有著非常大的不同。

劉勇：首先，SSR 是需要服務(wù)器資源成本的，在降本提效的大背景下，會(huì)需要結(jié)合 Serverless 或邊緣計(jì)算等一些基建才能找到平衡點(diǎn)。同時(shí)既然是服務(wù)端，就有一定的運(yùn)維能力要求，對(duì)前端團(tuán)隊(duì)的技術(shù)積累有一定的要求。

其次，框架的封裝和維護(hù)如果做的不好的話，業(yè)務(wù)同學(xué)寫(xiě) SSR 很容易弄出內(nèi)存泄露問(wèn)題，這是非常常見(jiàn)的。而且目前的前端框架還沒(méi)有針對(duì) SSR 場(chǎng)景進(jìn)行優(yōu)化，如果只是首屏展示快，但緊接著要下載超大的 Bundle 文件，從而用戶可交互時(shí)間太慢，就得不償失了。

最后，演進(jìn)路徑問(wèn)題，譬如螞蟻那邊，他們當(dāng)年就已經(jīng)跟把離線包的上下游基建都做的很完善了，APP 側(cè)、網(wǎng)絡(luò)側(cè)都有兄弟團(tuán)隊(duì)配合一起打磨。這種模式會(huì)有一些缺陷，如離線包太多時(shí)的業(yè)務(wù)競(jìng)爭(zhēng)問(wèn)題，但就首屏性能這一點(diǎn)上，SSR 不一定比它好多少，這時(shí)候讓他們切換到 SSR 就會(huì)有不小的阻力。

Q6：有評(píng)論認(rèn)為 SSR 開(kāi)發(fā)和維護(hù)成本太高了，轉(zhuǎn)而投向了 CSR 的懷抱。CSR 能否取得跟 SSR 一樣的效果呢？有什么具體的操作方案嗎？

劉勇：從首屏性能的關(guān)鍵點(diǎn)看，CSR 如果不做一定的優(yōu)化的話，至少 3 次串行的 HTTP 請(qǐng)求，首屏?xí)r間肯定比不過(guò) SSR（互操作時(shí)間就不一定）。

不過(guò)相應(yīng)的解決方案也挺多的，如 ServiceWorker、離線包等等方式。

劉奎：?jiǎn)螐氖灼龄秩舅俣冗@一點(diǎn)來(lái)看，CSR 想取得 SSR 類似的效果，可以采取以下方案優(yōu)化：

首屏頁(yè)面靜態(tài)資源優(yōu)化：通過(guò)代碼切割 & 懶加載等手段，確保首屏需要的 JS/CSS 是最小化的版本，并通過(guò)內(nèi)聯(lián)等方式直接打到 HTML 中，減少首屏渲染需要的網(wǎng)絡(luò)請(qǐng)求；

緩存和預(yù)加載：利用客戶端的緩存及預(yù)加載等機(jī)制，提升二次訪問(wèn)速度；

使用更輕量的框架：選擇更輕量的前端框架，從而減少首屏的 JS 體積，提升加載速度；

優(yōu)化關(guān)鍵接口響應(yīng)速度：優(yōu)化首屏需要的關(guān)鍵內(nèi)容的接口響應(yīng)速度，確保前端能更快的呈現(xiàn)頁(yè)面。

但如果還有額外的 SEO 訴求，單純的 CSR 可能很難達(dá)到一樣的效果。

Q7：如果將原有的應(yīng)用直接切換到 SSR 一體化應(yīng)用中來(lái)，成本會(huì)有多大？對(duì)開(kāi)發(fā)團(tuán)隊(duì)會(huì)有哪些挑戰(zhàn)呢？

劉奎：成本及挑戰(zhàn)有以下幾點(diǎn)：

應(yīng)用改造成本：大部分應(yīng)用都是無(wú)法直接在服務(wù)端環(huán)境運(yùn)行的，基本都需要做一定程度的改造，比如消除首屏渲染代碼中對(duì) window、location 等瀏覽器特有 API 的依賴，構(gòu)建出用于服務(wù)端運(yùn)行的 JS 等。

SSR 函數(shù)研發(fā)及運(yùn)維挑戰(zhàn)：同時(shí)具備豐富的前端及服務(wù)端開(kāi)發(fā)經(jīng)驗(yàn)的團(tuán)隊(duì)在大部分公司都是非常少見(jiàn)的，如前面提到的，SSR 帶來(lái)的額外的服務(wù)端的開(kāi)發(fā)及運(yùn)維挑戰(zhàn)，這個(gè)也是需要前端團(tuán)隊(duì)考慮的。

也需，SSR+CSR 會(huì)是未來(lái)新方向？ Q8：現(xiàn)在一些網(wǎng)站采用了首屏服務(wù)器端渲染，即對(duì)于用戶最開(kāi)始打開(kāi)的那個(gè)頁(yè)面采用的是服務(wù)器端渲染，這樣就保證了渲染速度，而其他的頁(yè)面采用客戶端渲染，這樣就完成了前后端分離。你覺(jué)得這會(huì)是融合了兩者優(yōu)勢(shì)的更完美的方案嗎？

劉奎：是的，這也是目前社區(qū)內(nèi)的最佳實(shí)踐，能很好的保留 SSR 及 SPA 應(yīng)用的優(yōu)點(diǎn)。

劉勇：這其實(shí)很多年前就有相關(guān)實(shí)踐了，譬如當(dāng)年云龍?jiān)?UC 的 Scrat Pagelet 就是類似的實(shí)踐，甚至當(dāng)時(shí)做的是后續(xù)頁(yè)面也通過(guò)服務(wù)端局部渲染，按需更新前端頁(yè)面的階段。

這種方式在業(yè)界也有看到一些更近一步的實(shí)踐：開(kāi)發(fā)者很自然的去寫(xiě)邏輯，不用管什么分離不分離的事，在前端工程化那一層自動(dòng)拆分，SSG + SSR + CSR，一些可以靜態(tài)構(gòu)建的直接在構(gòu)建階段處理了，一些可以在服務(wù)端渲染的服務(wù)端，剩下的非剛需的組件直接前端渲染掉。這些都能做，前提是前端工程化這塊的基建是否足夠完善，研發(fā)模式是否足夠收斂。

最后提醒下，我所了解大部份 SSR 實(shí)踐，一般也會(huì)在前面再擋一個(gè)短時(shí)效的 CDN，然后通過(guò) CSR 做千人千面的修飾和后續(xù)業(yè)務(wù)邏輯。

Q9：你如何看待 SSR 的未來(lái)發(fā)展？是會(huì)隨著硬件的升級(jí)逐步淘汰，還是會(huì)隨著技術(shù)的更新越發(fā)流行？

劉勇：優(yōu)化思路是不會(huì)過(guò)時(shí)的，也許某一天我們現(xiàn)在熟悉的 SSR 的編程界面變了，譬如當(dāng)年的 SSR 是用 nunjucks、ejs 之類的模版，現(xiàn)在是 react、vue。未來(lái)也會(huì)有新的技術(shù)出現(xiàn)，但它很有可能也屬于 SSR 的一種實(shí)踐模式。

劉奎：按照我的經(jīng)驗(yàn)來(lái)看，很多時(shí)候新的技術(shù)方案大都會(huì)嘗試更多的壓榨硬件機(jī)能，從而獲得更好的交互體驗(yàn)，所以任何時(shí)期都會(huì)存在相對(duì)「低端」的設(shè)備，這個(gè)應(yīng)該是解決不掉的（笑

在我看來(lái)，SSR 最主要的落地成本還是在服務(wù)端的研發(fā)及運(yùn)維上，這個(gè)對(duì)于大部分公司的前端團(tuán)隊(duì)都是較大的負(fù)擔(dān)，進(jìn)而因?yàn)?ROI 不高導(dǎo)致 SSR 落地困難。但是，隨著 Serverless 的發(fā)展，出現(xiàn)了許多幾乎 “零運(yùn)維” 的 Serverless 方案，可以極大地降低前端團(tuán)隊(duì)的運(yùn)維成本。同時(shí)，從社區(qū)的趨勢(shì)來(lái)看，近年來(lái)流行的各種前端框架都在擁抱 Edge 和 SSR，例如 Next.js、remix-run、Qwik、Astro、Fresh 等。同時(shí)，React 等庫(kù)也推出了性能表現(xiàn)更佳的流式 SSR 能力。通過(guò)這些框架技術(shù)的集成和迭代，不僅可以顯著降低前端工程師開(kāi)發(fā) SSR 應(yīng)用的研發(fā)成本，還能進(jìn)一步提升傳統(tǒng) SSR 的性能效果。

從目前的趨勢(shì)來(lái)看，我覺(jué)得 SSR 會(huì)隨著研發(fā)及運(yùn)維成本的降低，變得越發(fā)的流行。

Q10：結(jié)合你的項(xiàng)目經(jīng)驗(yàn)，你會(huì)如何評(píng)價(jià) SSR 這一模式呢？

劉勇：從前端的歷史演進(jìn)看，是 SSR → CSR → SSR，粗一看似乎是在開(kāi)歷史倒車，但實(shí)際不然。

舉個(gè)例子，當(dāng)年前端的 HTML + CSS + JS 都是 all-in-one 的單文件方式，因?yàn)槟菚r(shí)候前端沒(méi)有編譯能力只能寫(xiě)在一起；隨著前端工程化的演進(jìn)，開(kāi)發(fā)期拆成多文件方式進(jìn)行組織，構(gòu)建時(shí)自動(dòng)處理成為了主流；再進(jìn)一步又出現(xiàn)了類似 Vue SFC 這樣的單文件方式，這是開(kāi)倒車么？其實(shí)不是，而是隨著基建的完善，用戶編程界面是可以更貼近直覺(jué)的，性能和部署之類的事交給工具去做即可。

因此，我認(rèn)為 SSR 模式是有真實(shí)場(chǎng)景的，但在目前這個(gè)階段，我覺(jué)得它還有很多切實(shí)的性能問(wèn)題和工程化問(wèn)題需要解決才能更好的落地。

劉奎：CSR 雖然也能獲得比較好的首屏體驗(yàn)，但受限于用戶設(shè)備的機(jī)能，存在著明顯的性能天花板。而 SSR 則能更好的借助邊緣計(jì)算（ESR）、流式渲染等服務(wù)端能力，有效的提升性能天花板，在大部分時(shí)候會(huì)是 Web 應(yīng)用提升首屏性能的一個(gè)有效武器。

當(dāng)然每個(gè)項(xiàng)目和團(tuán)隊(duì)都有不同的特點(diǎn)和目標(biāo)，在選擇開(kāi)發(fā)模式時(shí)需要綜合考慮各種因素。

對(duì)此，你怎么看？你的項(xiàng)目采取了 SSR 還是 CSR 呢？快來(lái)評(píng)論區(qū)說(shuō)說(shuō)你的體驗(yàn)吧～