背景：
以前：沒有服務端渲染的概念，大規模應用之前，用戶請求網頁，都是後端先調用數據庫，獲得數據之後，將數據和頁面元素進行拼裝，組合成完整的 html 頁面，再直接返回給瀏覽器，以便用戶瀏覽，
優點：利於SEO，首屏快。
缺點：直接操作dom，性能差，代碼管理混亂，不適合大工程，開發兼顧前後臺，無法做到分工明確。
現在：前後端分離，依賴於接口，並且單頁應用得到了廣泛應用（Angular、React、Vue 前端三大框架），後端專注於數據接口服務，前端專注接口調用，取得數據後渲染頁面，
優點：分工明確，工程清晰，易於維護，虛擬dom性能高，滿足日漸發展的前端需求。
缺點：不利於SEO（搜索引擎並不能收錄到 ajax 爬取數據之後然後再動態 js 渲染出來的頁面），首屏慢（單頁應用由於一次性將代碼發送給瀏覽器，代碼過大導致首屏慢）。
好了，現在前後端分離解決了以前的很多痛點，但他卻帶來了一些新的痛點，於是有人說，那前後端分離、單頁應用還不是雞肋。事實上，它重新帶來的痛點遠遠沒有傳統的痛點大，而且有很多項目對SEO和首屏的依賴性並不強，比如後臺管理系統，比如ERP等等，而且首屏渲染依然不是問題，有webpack等打包工具的按需加載之後，可以解決首屏慢的問題，那對於SEO依賴性強的項目是不是就沒法使用單頁應用了呢？答案是否定的，服務端渲染可以解決SEO問題，而且還能讓首屏更快
什麼是服務器端渲染？
分工明確，工程浩大，前後端分離無疑是未來趨勢，但針對致命的SEO和和首屏慢，有何解決方法，服務端渲染由此而生、簡單理解是將組件或頁面通過服務器生成html字符串，再發送到瀏覽器，即數據和頁面在服務器端就已經被渲染成完整的html文檔，無需瀏覽器再通過接口訪問數據再渲染。進而解決SEO（頁面已經完整，爬蟲可以爬取到頁面所有內容），首屏慢（服務器端進行代碼分隔，按需加載，只給瀏覽器有需要的資源）的問題。
附：對“代碼分割、按需加載”的解釋：即首次訪問home，服務器只返回home頁面，與home頁面無關的資源不會加載，點擊跳轉路由至list，服務器返回list頁面，與list頁面無關的資源不會加載，此時該單頁應用就已經將home和list都發至瀏覽器了，再次路由切換訪問home時，不會發請求要home頁面，這就是服務器端渲染解決了單頁應用的致命問題，同時不影響單頁應用的用戶體驗。
單頁應用，使用的是客戶端渲染：
其渲染流程如下：
1. 請求一個html
2. 服務端返回一個html
3. 瀏覽器下載html裏面的js/css文件
4. 等待js文件下載完成
5. 等待js加載並初始化完成
6. js代碼終於可以運行，由js代碼向後端請求數據( ajax/fetch )
7. 等待後端數據返回
8. 客戶端從無到完整地，把數據渲染爲響應頁面
計算一下：至少需要向服務器同步請求三次數據
而服務端渲染過程如下：
1. 請求一個html
2. 服務端請求數據( 內網請求快 )
3. 服務器初始渲染（服務端性能好，較快）
4. 服務端返回已經有正確內容的頁面
5. 客戶端請求js/css文件
6. 等待js文件下載完成
7. 等待js加載並初始化完成
8. 客戶端把剩下一部分渲染完成( 內容小，渲染快 )
計算一下：一共至多需要向服務器同步請求兩次次數據
附：對同一個組件，服務端渲染“可視的”一部分( render/componentWillMount部分代碼 )，爲確保組件有完善的生命週期及事件處理，客戶端需要再次渲染。即：服務端渲染，實際上也是需要客戶端進行 再次地、但開銷很小的二次渲染。
服務端渲染之next.js？（next.js對應的是react，如果你只會Vue，請對應自行學習Nuxt.js）
Next.js是一套基於React的服務器端渲染框架。在React模塊化的基礎上，帶來以下幾點好處：
1、默認服務端渲染模式
2、代碼自動分隔使頁面加載更快
3、以文件系統爲基礎的客戶端路由
4、以webpack的熱替換爲基礎的開發環境
5、使用React的JSX和ES6的module，模塊化和維護更方便
6、可以運行在Express和其他Node.js的HTTP 服務器上
7、可以定製化專屬的babel和webpack配置
next.js詳細使用，請查看官方文檔：https://nextjs.frontendx.cn/
