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，或許你有更好的答案，也可以留言告訴我。