你可能不需要 SSR

現今 SSR 框架當道，什麼都要搞 SSR 框架，Nuxt, Next, Universal，各種技術不斷興起。前後端花了近十年分離的架構即將又要融合為一塊，這就是現在網頁前端的趨勢。

先看 SSR 帶來的三個好處

我們先分析 SSR 帶來的好處：

• 能倚賴 Server 提供 HTML 結構，可以讓爬蟲能更快更容易爬到動態的資訊內容，以提供最佳化的 SEO 效果。
• Server 端的運算力相對可控，能在有效率的情境下提供渲染運算，減輕 Client 的運算負載，提高 FP, FCP，讓使用者更快看到畫面。
• 減少 CLS ，讓畫面一開始就不會重複渲染。

但這些問題，真的是問題嗎？

但這些問題真的是問題嗎？

關於 SEO 的問題，其實真正需要的應該是建立 SSG Service ，提前預渲染 HTML，最快速提供 HTML 給爬蟲爬。有多少網站真的需要「非常動態」去產生 HTML 呢？其實跑個排程定期去 Generation HTML 就非常足夠，只有極少高頻率更新的網頁需要 SSR 這麼動態產出。

關於渲染效率問題，Server 一開始就提供資料雖然感覺上更快提供資料，但伺服器之間相互通訊也是得消耗一定的時間。換言之，當伺服器因為資料量過大而撈取過久的時間，對於使用者並沒有感到更快。反而如果先提供基本的 Layout Container，再以非同步方式去更新和追究資料，還能讓使用者更有預期的去等待資料完成。

關於 CLS 本身就不該是問題，切版本來就要考慮設計出來的容器大小，不要過度依賴資料撐出寬高，得考量更多更複雜的版面情境。

仔細想想，你的網站真的非 SSR 不可嗎？

再看 SSR 帶來的副作用

如果看看 SSR 帶來的副作用：

• 當架構簡單時，甚至要為了 SSR 多開一組 Service 的資源。
• 處理資料流更複雜，前端同時要整合伺服器和瀏覽器的狀態和資料流。
• 架構變得更複雜，原本簡單的 Client 議題可能到了 SSR 架構複雜度上升好幾個等級。包含多國語系、權限管理、使用者裝置判斷渲染⋯⋯
• 表面上降低初始載入資料量，實際上在傳輸過程中，SSR 要多承擔 HTML 的資料，和不亞於 CSR 的 JavaScript 綑綁資料。

不是沒有價值，是大部分情況真的不需要

並不是 SSR 毫無價值，完全不需要，但大部分情況真的不需要。有時實在覺得不需要追流行追技術，能更簡單容易的解決問題才是商業上更需要的。或許時空背景上，未來又有不同的結論，但現在來講，我還不是很認同過度追求 SSR。