這幾天服務端渲染在知乎上熱度又上來了，于是我又去翻看了一些相關資料。

服務端渲染是什么

我最開始接觸是在Vue的官網(wǎng)上，開始是作為一個小節(jié)出現(xiàn)，現(xiàn)在已經(jīng)是個專門的大章節(jié)來專門講Vue服務端渲染的內容。

服務端渲染 簡單來說就是在服務器上把數(shù)據(jù)和模板拼接好以后發(fā)送給客戶端顯示。

回顧下前端的歷史，最開始的站點是簡單的靜態(tài)網(wǎng)站。后端大哥把.html文件推送給用戶，用戶瀏覽器解析這些字符串進行顯示。那個時候就是 服務端渲染 。可是后來由于網(wǎng)站內容越來越復雜、特效越來越炫酷，這種‘兼職’狀態(tài)已經(jīng)不能滿足需求，細分之下的前端出現(xiàn)了。

隨后為了方便的開發(fā)，開始提倡 前后端分離，大家各做個的，彼此之間通過基于HTTP的各種API協(xié)作，變成了數(shù)據(jù)動態(tài)生成的新一代站點。

再后來出現(xiàn)了Vue等三大MV*框架，網(wǎng)站做成了SPA應用，解決了很多問題的同時也帶來了新問題，其中最突出的兩個：難以SEO和首屏加載緩慢。

服務端渲染解決了什么

難以SEO
SPA網(wǎng)站們不僅數(shù)據(jù)是動態(tài)生成的，連大部分DOM節(jié)點都是動態(tài)生成的，后臺只提供一個基本模板，而內容需要等到各種JS文件在客戶端下載運行完成以后才能顯示。
而搜索引擎目前并不會去下載這些JS文件來爬數(shù)據(jù)（據(jù)說 Google 已經(jīng)有了這項技術并在使用，百度也能這樣做但沒做），那么在搜索引擎改變策略前，總得想點辦法。

時尚就是輪回，現(xiàn)在前端竟然也有這個現(xiàn)象...那么大神們想到了辦法：那就讓我們回到老路上吧。

得益于Node.js的出現(xiàn)，不需要后臺做太多，把數(shù)據(jù)和模板在中間服務器上進行組裝，再發(fā)送給客戶端。這樣的模式解決了問題又沒有讓大家倒退回去，大廠們沖鋒在前，提出各種實踐方案，這里有美團的大神發(fā)布的兩篇文章：

美團點評點餐前后端分離實踐——一個可能沒用現(xiàn)成框架
美團點評點餐 Nuxt.js 實戰(zhàn)——一個用了Nuxt.js框架

珠玉在前，我也說不了太深，有興趣請看文章。

首屏加載緩慢
隨著前端的發(fā)展，業(yè)務邏輯越來越復雜，代碼也越來越厚，各種JS文件越來越大，當一個網(wǎng)頁打開，所有東西都下載完頁面能打開，白屏時間越來越長。

為了解決這個問題，代碼模塊化 和 按需加載、占位圖 和 預展示 紛紛開始應用，從不同的角度削減了問題程度。但是服務端渲染同樣也是解決這個問題的角度之一，由于不少資源在中間服務器上進行拼接，節(jié)省了客戶端的不少時間，效果也很不錯。

服務端渲染有什么缺點

在解決問題的同時同樣也有一些成本是必須要考慮的。

首先是 技術成本，中間增加了這些環(huán)節(jié)當然要多更多的時間或更多的人來完成，并且還有不少坑要踩。

然后很多計算從客戶端移到服務器上，對服務器的壓力增加，特別是高并發(fā)時會給服務器的 CPU 帶來更大的負載。

結語

我個人覺得用不用、怎么用依然得看需求和取舍，技術是工具，主要還是看人。