接觸過SPA（單頁應用）的世界後，現在來看SSR的資料我感到萬分痛苦…。我們先假想在不久後的將來，也許某天Boss說：「這個系統從SPA改成SSR」我們會想起這天含著淚研讀後的成果…

◎先說結論：原本是想在現有專案直接加入SSR的，但是難度對我來說還是太高了，我們試著先理解Vue-SSR在做什麼（別想著越級打怪啊！TT）

先搞懂我要什麼R

• CSR（Client-Side-Render）：瀏覽器執行js後才開始在客端進行頁面內容的渲染和DOM綁定（就像是吃鐵板燒，師傅會在你面前對食材進行一連串的料理過程，最後才會拿到擺盤完的食物）
• SSR（Server-Side-Render）：請求發送後，由伺服器進行渲染，最後將組合好的Html和css整包丟給瀏覽器顯示（在廚房完成所有料理過程，端到你面前已經是一盤完美即可享用的義大利麵）

怎麼選全看SEO： 當然雙方各有優缺點，網路上種種比較：CSR引入太多JS初始載入太慢、SSR一直跳動使用者體驗不佳…但最大的差別還是在於多數瀏覽器不支援JS解析，因此SSR在SEO（搜尋引擎最佳化）上的表現更好！

Vue-SSR 明知有雷偏要踩

• 典型SSR專案源文件架構

– index.html
– server.js # main application server
– src/
– main.js # 導出跟環境無關的（通用的）應用代碼
– entry-client.js # 將應用掛載到DOM元素上
– entry-server.js # 使用某框架的SSR API渲染該應用

事實上，當前端框架盛行的時代又要讓SEO好好表現，是有很多熱門的混搭用法讓開發者可以更有效的處理SEO的問題：Vue ft. Nuxt.js。但如果你仍考慮要透過Vue-SSR來開發不如看看以下的提示：

• 雷在哪：Vue.js 是一個用於建構客戶端應用程序的框架，然後半路我們才要請伺服器端渲染加入…簡直是矛與盾大對決！
  1. 響應狀態失效：讓伺服器端進行渲染輸出的動作，客端的響應性就顯得多餘了點
  2. 生命鉤子在伺服器渲染階段不會被調用，我們寫在Hooks中的程式碼就會失效，有副作用需要被註銷的語法後續就會延伸出問題
  3. 跨請求的狀態被汙染：在CSR的狀態下，模快會在每個瀏覽器的訪問時被初始化，因此不會互相影響；但SSR的情況通常是在伺服器啟動時初始化，但期間內會面對多個服務器的請求導致複用而被汙染
  4. 自定義指令一樣在SSR下不會被渲染，需要改寫套用getSSRProps指令鉤子才會有作用
• 來自官網的再三勸退：

在為你的應用使用 SSR 之前，你首先應該問自己是否真的需要它。這主要取決於首屏加載速度對應用的重要程度。例如，如果你正在開發一個內部的管理面板，初始加載時的那額外幾百毫秒對你來說並不重要，這種情況下使用 SSR 就沒有太多必要了。如果你調研 SSR 只是為了優化為數不多的營銷頁面的 SEO (例如 /、/about 和 /contact 等)，那麼你可能需要 SSG 而不是 SSR。SSG 也非常適合構建基於內容的網站，例如文檔站點或者博客。

改成這樣不如重寫： 困難點就是在於原先符合CSR需求的語法，全都要因為SSR加進來之後全部變調！就這樣，雖然Vue發展到後期也提供了具備SSR的服務，但看完這些數不盡的延伸問題：我真的不要了。

Nuxt.js做了什麼

Nuxt.js是基於Vue.js所發展的框架，主要就是要來解決CSR辦不到也很難辦到的SSR和SEO問題：

• 保有靜態SPA：讓剛使用的開發者也能 漸進式入手！
• SSG靜態站點生成： 預先渲染所有頁面 ，即便不需要SSR也能解決SEO的問題！
• 更高效的SSR：以 Vue組件為基礎 到伺服器渲染而非純js，包裝js&css達到最輕量！

還有什麼很酷的事情？

• 自動代碼分離
• 路由支持異步數據自動生成
• 支援ES6語法
• 少不了的熱重載
  
  ▲Nuxt.js的流程圖

小結

寫這篇文章的初衷從「我要試著把現有專案套用Vue-SSR！」變成了「少走點冤望路吧」，雖然真的是因為能力不足改寫不成TT。但每次的失敗就會促成認識新技術的開始，有機會再來入手Nuxt.js！

參考資料
手把手建立Vue-SSR開發環境
服務端渲染 (SSR)
SSR 還是 CSR？ 3 分鐘了解網頁渲染對 SEO 的影響
什麼是 CSR (SPA) 與 SSR？如何影響 SEO？ 優缺點與誤解完整分析 (Rendering)
Nuxt.js