最近在把一個c端的項目重構成首屏服務端渲染（SSR：server side render）
項目用到的技術： React 、webpack、koa2、webpack
對于重構成SSR，redux并不是必須的，是以沒用redux
本篇文章先講述一些理論的東西，之後會寫代碼篇
一、 什麼是服務端渲染
簡單了解是将元件或頁面通過伺服器生成html字元串，再發送到浏覽器，最後将靜态标記"混合"為用戶端上完全互動的應用程式
如下圖所示，
左圖頁面沒使用服務渲染，當請求user頁面時，傳回的body裡為空，之後執行js将html結構注入到body裡，結合css顯示出來；
右圖頁面使用了服務端渲染，當請求user頁面時，傳回的body裡已經有了首屏的html結構，之後結合css顯示出來
二、 使用SSR的利弊
SSR的優勢
- 更利于SEO。
不同爬蟲工作原理類似，隻會爬取源碼，不會執行網站的任何腳本（Google除外，據說Googlebot可以運作javaScript）。使用了React或者其它MVVM架構之後，頁面大多數DOM元素都是在用戶端根據js動态生成，可供爬蟲抓取分析的内容大大減少(如圖一)。另外，浏覽器爬蟲不會等待我們的資料完成之後再去抓取我們的頁面資料。服務端渲染傳回給用戶端的是已經擷取了異步資料并執行JavaScript腳本的最終HTML，網絡爬中就可以抓取到完整頁面的資訊。
2. 更利于首屏渲染
首屏的渲染是node發送過來的html字元串，并不依賴于js檔案了，這就會使使用者更快的看到頁面的内容。尤其是針對大型單頁應用，打包後檔案體積比較大，普通用戶端渲染加載所有所需檔案時間較長，首頁就會有一個很長的白屏等待時間。
SSR的局限
- 服務端壓力較大
本來是通過用戶端完成渲染，現在統一到服務端node服務去做。尤其是高并發通路的情況，會大量占用服務端CPU資源；
- 開發條件受限
在服務端渲染中，隻會執行到componentDidMount之前的生命周期鈎子，是以項目引用的第三方的庫也不可用其它生命周期鈎子，這對引用庫的選擇産生了很大的限制；
- 學習成本相對較高
除了對webpack、React要熟悉，還需要掌握node、Koa2等相關技術。相對于用戶端渲染，項目建構、部署過程更加複雜。
三、 時間耗時比較
- 資料請求
由服務端請求首屏資料，而不是用戶端請求首屏資料，這是“快”的一個主要原因。服務端在内網進行請求，資料響應速度快。用戶端在不同網絡環境進行資料請求，且外網http請求開銷大，導緻時間差。 下圖為服務端渲染的資料請求路線和用戶端渲染的資料請求路線圖
- html渲染
服務端渲染是先向後端伺服器請求資料，然後生成完整首屏html傳回給浏覽器；而用戶端渲染是等js代碼下載下傳、加載、解析完成後再請求資料渲染，等待的過程頁面是什麼都沒有的，就是使用者看到的白屏。就是服務端渲染不需要等待js代碼下載下傳完成并請求資料，就可以傳回一個已有完整資料的首屏頁面。
具體流程可參考下面兩張圖