最近在把一個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的優勢
1. 更利于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代碼下載完成并請求數據，就可以返回一個已有完整數據的首屏頁面。
具體流程可參考下面兩張圖
