3202年了，為啥SSR并沒有預想中的流行？

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

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

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

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

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

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

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

SSR，并不是偽需求

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

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

電商平臺：更快的首屏渲染可以讓用戶更快的看到商品信息，提升購買轉化率

營銷活動頁：秒開能有效提升營銷活動的業(yè)務效果

門戶網(wǎng)站：內容型站點通常對 SEO 有著比較強的訴求

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

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

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

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

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

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

劉勇：根據(jù)團隊的基建成熟度和業(yè)務場景做技術選型，這 2 個方案沒有絕對的優(yōu)劣，也不是絕對的割裂，它們是可以通過前端工程化結合成一個方案的。

SSR，想紅有點難 Q5：以當前的形勢來看，SSR 并沒能成為 Web 主流的開發(fā)模式，你覺得這其中的阻礙有哪些？

劉奎：我覺得主要有這幾類原因：

技術復雜度：SSR 需要在服務器端進行渲染，并與前端框架進行集成，對開發(fā)人員來說需要掌握更多的技術知識。

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

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

劉勇：首先，SSR 是需要服務器資源成本的，在降本提效的大背景下，會需要結合 Serverless 或邊緣計算等一些基建才能找到平衡點。同時既然是服務端，就有一定的運維能力要求，對前端團隊的技術積累有一定的要求。

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

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

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

劉勇：從首屏性能的關鍵點看，CSR 如果不做一定的優(yōu)化的話，至少 3 次串行的 HTTP 請求，首屏時間肯定比不過 SSR（互操作時間就不一定）。

不過相應的解決方案也挺多的，如 ServiceWorker、離線包等等方式。

劉奎：單從首屏渲染速度這一點來看，CSR 想取得 SSR 類似的效果，可以采取以下方案優(yōu)化：

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

緩存和預加載：利用客戶端的緩存及預加載等機制，提升二次訪問速度；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

從目前的趨勢來看，我覺得 SSR 會隨著研發(fā)及運維成本的降低，變得越發(fā)的流行。

Q10：結合你的項目經(jīng)驗，你會如何評價 SSR 這一模式呢？

劉勇：從前端的歷史演進看，是 SSR → CSR → SSR，粗一看似乎是在開歷史倒車，但實際不然。

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

因此，我認為 SSR 模式是有真實場景的，但在目前這個階段，我覺得它還有很多切實的性能問題和工程化問題需要解決才能更好的落地。

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

當然每個項目和團隊都有不同的特點和目標，在選擇開發(fā)模式時需要綜合考慮各種因素。

對此，你怎么看？你的項目采取了 SSR 還是 CSR 呢？快來評論區(qū)說說你的體驗吧～