Nic Lin's Blog

喜歡在地上打滾的 Rails Developer

淺述 SSR SPA 優缺點

SSR(Server Side Rendering) 伺服器端渲染

以往的應用架構幾乎都是從 Server side 渲染,由伺服器端的 CPU 收到請求後,解析完整的 HTML 返回到使用者接收端,然後呈現網頁。

這樣的作法不論點擊什麼網頁上什麼功能,每一次都是將整個畫面重新繪製,如果在頻寬網路較差的情況下,會是一個較不好的體驗,因為要一直重新 loading 整個頁面。

理想的狀況應該是,希望哪一個畫面區塊變動,就只要重新繪製那個小區塊就好,也就是局部刷新,所以也有了後來 AJAX 的出現。

那麼伺服器端渲染的優點是什麼呢?

  • SEO
  • 不需要先下載一堆 JS 和 CSS 後才能看到頁面(首屏加載速度快)
  • 伺服器端渲染不需關心瀏覽器兼容的問題(隨著瀏覽器不斷的發展,這個點將不再這麼重要)
  • 對於設備性能較弱的手機或平版,減少 client side 的電量消耗

不過優點大概只剩下 SEO 和 首屏加載速度快較為突出,剩下的其實現代前端框架有支持同構(Hybird)幾乎都能處理了。

SPA(Single Page Application) 單頁式應用

前端渲染遇到的問題,就剛好是上面提到 SSR 優點的相反啦 XD

  • SEO
  • 首屏性能

SPA 打包的 JS 往往都比較大,會導致頁面加載後花費很長的時間來解析。

也因為 SEO robot 基本上只會從 HTML 抓取數據,會導致前端渲染的頁面無法被抓取資料(不過現在 Google 也可以爬 JS 了)

但其優點相較於 SSR,減少頻寬浪費,較好的使用體驗(不需重新渲染整個頁面,局部刷新)。

同構、Hybird、混合

指的是可以讓前端框架既支援 SPA,也有初次加載的 SSR,第一個頁面由 Server side render,之後的操作還是由 Client side render。

以 React 的 SSR 作法來說,先讓程式碼在 server 上被執行一次,把 HTML 倒出來直接顯示,也因為 HTML 已經包含網頁中所有的資訊,所以 SEO 也沒有問題了,然後這時再讓 React 的程式碼被運行,為 HTML 中的內容新增資料及事件的聯繫,也擁有的 SPA 的互動能力。

不過這種技術架構也會讓原本的 React 專案變的複雜。

除非你的專案流量大量來自於搜尋引擎流量,或是對首屏加載時間有高度要求,不然不建議在這邊用 SSR

如果做一個像是 medium 的 CMS 網站,要用 SPA? SSR? 還是混合?

之前面試被問到的問題,我覺得遇到這類問題,也可以稍微思考一下該用哪種技術架構才最適合?

媒體類的網站,會有依賴搜尋引擎必要的,我認為會比較以 SSR 為主,一來在一開始的開發成本、維護成本會比較小,也還暫時不需要為了處理 SEO 而把專案搞複雜了。

然而在編輯器編輯文章時,我認為這部分就可以做 SPA,比方說熱鍵儲存草稿、預覽之類的小功能,就不需要在重新 loading 網頁或是打開分頁,可以直接渲染(當然,嫌 SPA 麻煩用 AJAX 做掉也可以 XD)。

所以我的答案會是 SSR + SPA 都做的 Hybird(混合)方式 XD,或許你有更好的答案,也可以留言告訴我。

comments powered by Disqus