后端渲染

互聯(lián)網(wǎng)早期，用戶使用瀏覽器瀏覽的都是一些沒(méi)有復(fù)雜邏輯的、簡(jiǎn)單的頁(yè)面，服務(wù)器進(jìn)程從數(shù)據(jù)庫(kù)獲取數(shù)據(jù)后，后端的程序在把HTML頁(yè)面吐給前端之前，先把HTML頁(yè)面上的特定區(qū)域、特定符號(hào)，先用數(shù)據(jù)填充，將數(shù)據(jù)加載進(jìn)來(lái)生成HTML，然后通過(guò)網(wǎng)絡(luò)傳輸?shù)接脩舻臑g覽器中解析成可見的頁(yè)面。

前端渲染

隨著前端頁(yè)面的復(fù)雜性提高，前端就不僅僅是普通的頁(yè)面展示了，而可能添加了更多功能性的組件，復(fù)雜性更大，另外，彼時(shí)ajax的興起，使得業(yè)界就開始推崇前后端分離的開發(fā)模式，即后端不提供完整的HTML頁(yè)面，而是提供一些API使得前端可以獲取到JSON數(shù)據(jù)，然后前端拿到JSON數(shù)據(jù)之后再在前端進(jìn)行HTML頁(yè)面的拼接，然后展示在瀏覽器上，這就是所謂的前端渲染。
這樣前端就可以專注UI的開發(fā)，后端專注于邏輯的開發(fā)。代表是現(xiàn)在流行的SPA單頁(yè)面應(yīng)用，例如Vue、React框架，只需要后端給我們提供接口API，前端UI、交互等全在前端進(jìn)行，前后端只需要約定接口。

前端渲染路線

1. 請(qǐng)求一個(gè)HTML
2. 服務(wù)端返回一個(gè)HTML
3. 瀏覽器下載html里面的JS/CSS文件
4. 等待JS文件下載完成
5. 等待JS加載并初始化完成
6. JS代碼終于可以運(yùn)行，由JS代碼向后端請(qǐng)求數(shù)據(jù)(ajax/fetch)
7. 等待后端數(shù)據(jù)返回

8. 客戶端從無(wú)到完整地，把數(shù)據(jù)渲染為響應(yīng)頁(yè)面

后端渲染路線

1. 請(qǐng)求一個(gè)HTML
2. 服務(wù)端請(qǐng)求數(shù)據(jù)(內(nèi)網(wǎng)請(qǐng)求快)
3. 服務(wù)器初始渲染(服務(wù)端性能，較快）
4. 服務(wù)端返回已經(jīng)有正確內(nèi)容的HTML
5. 客戶端請(qǐng)求JS/CSS文件
6. 等待JS文件下載完成
7. 等待JS加載并初始化完成

8. 客戶端把剩下一部分渲染完成(內(nèi)容小，渲染快)

后端渲染與前端渲染的優(yōu)缺點(diǎn)對(duì)比

SPA

SPA：?jiǎn)雾?yè)Web應(yīng)用（single page web application，SPA），就是只有一張Web頁(yè)面的應(yīng)用，是加載單個(gè)HTML 頁(yè)面并在用戶與應(yīng)用程序交互時(shí)動(dòng)態(tài)更新該頁(yè)面的Web應(yīng)用程序。

簡(jiǎn)單說(shuō)： Web不再是一張張頁(yè)面，而是一個(gè)整體的應(yīng)用，一個(gè)由路由系統(tǒng)、數(shù)據(jù)系統(tǒng)、頁(yè)面（組件）系統(tǒng)...組成的應(yīng)用程序，其中路由系統(tǒng)是非必須的。

大部分的Vue項(xiàng)目，本質(zhì)是SPA應(yīng)用，Angular.js、Angular、Vue、React...還有最早的"Pjax"均如此。

SPA時(shí)代，主要是在Web端使用了history或hash（主要是為了低版本瀏覽器的兼容）API，在首次請(qǐng)求經(jīng)服務(wù)端路由輸出整個(gè)應(yīng)用程序后，接下來(lái)的路由都由前端掌控了，前端通過(guò)路由作為中心樞紐控制一系列頁(yè)面（組件）的渲染加載和數(shù)據(jù)交互。

而上面所述的各類框架則是將以：路由、數(shù)據(jù)、視圖為基本結(jié)構(gòu)進(jìn)行的規(guī)范化的封裝。

最早的SPA應(yīng)用，由Gmail、Google Docs、Twitter等大廠產(chǎn)品實(shí)踐布道，廣泛用于對(duì)SEO要求不高的場(chǎng)景中。

SSR

SSR： 服務(wù)端渲染（Server Side Render），即：網(wǎng)頁(yè)是通過(guò)服務(wù)端渲染生成后輸出給客戶端。

在SPA之前的時(shí)代，我們的Web架構(gòu)大都是SSR，如：Wordpress（PHP）、JSP技術(shù)、JavaWeb...或者DEDECMS、Discuz!等這些程序都是傳統(tǒng)典型的SSR架構(gòu)，
即：服務(wù)端取出數(shù)據(jù)和模板組合生成html輸出給前端，前端發(fā)生請(qǐng)求時(shí)，重新向服務(wù)端請(qǐng)求html資源，路由也由服務(wù)端來(lái)控制。

其次，有個(gè)概念叫預(yù)渲染（Prerendering）。

如果你只是用服務(wù)端渲染來(lái)改善一個(gè)少數(shù)的營(yíng)銷頁(yè)面（如 首頁(yè)，關(guān)于，聯(lián)系 等等）的SEO，那你可以用預(yù)渲染來(lái)實(shí)現(xiàn)。
預(yù)渲染不像服務(wù)器渲染那樣即時(shí)編譯HTML，它只在構(gòu)建時(shí)為了特定的路由生成特定的幾個(gè)靜態(tài)頁(yè)面，等于我們可以通過(guò)webpack插件將一些特定頁(yè)面組件build時(shí)就編譯為html文件，直接以靜態(tài)資源的形式輸出給搜索引擎。

但實(shí)際的商業(yè)應(yīng)用中，大部分時(shí)候我們需要的是即時(shí)渲染，這也是我們今天討論的主題。

后端渲染優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

前端耗時(shí)少，因?yàn)楹蠖似唇油炅薍TML，不需要先下載一堆JS和CSS 后才能看到頁(yè)面，瀏覽器只需要直接渲染出來(lái)
搜索引擎優(yōu)化，因?yàn)樵诤蠖擞型暾腍TML頁(yè)面，所以爬蟲更容易爬取獲得信息，更有利于SEO
無(wú)需占用客戶端資源。即解析模板的工作完全交由后端來(lái)做，客戶端只要解析標(biāo)準(zhǔn)的HTML頁(yè)面即可，這樣對(duì)于客戶端的資源占用更少，尤其是移動(dòng)端，也可以更省電
后端生成靜態(tài)化文件。即生成緩存片段，這樣就可以減少數(shù)據(jù)庫(kù)查詢浪費(fèi)的時(shí)間了，且對(duì)于數(shù)據(jù)變化不大的頁(yè)面非常高效



缺點(diǎn)：

不利于前后端分離，開發(fā)效率低。使用服務(wù)器端渲染，則無(wú)法進(jìn)行分工合作，則對(duì)于前端復(fù)雜度高的項(xiàng)目，不利于項(xiàng)目高效開發(fā)
服務(wù)器端渲染，則前端一般就是寫一個(gè)靜態(tài)HTML文件，然后后端再修改為模板，這樣是非常低效的，并且還常常需要前后端共同完成修改的動(dòng)作
如果后端改了模板，前端還需要根據(jù)改動(dòng)的模板再調(diào)節(jié)CSS，這樣使得前后端聯(lián)調(diào)的時(shí)間增加
占用服務(wù)器端資源，即服務(wù)器端完成HTML模板的解析，如果請(qǐng)求較多，會(huì)對(duì)服務(wù)器造成一定的訪問(wèn)壓力。而如果使用前端渲染，就是把這些解析的壓力分?jǐn)偭饲岸耍@里確實(shí)完全交給了一個(gè)服務(wù)器

前端渲染優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

前后端分離，前端專注于前端UI，后端專注于API開發(fā)，且前端有更多的選擇性，而不需要遵循后端特定的模板
體驗(yàn)更好，比如，我們將網(wǎng)站做成單頁(yè)Web應(yīng)用（single page web application，SPA，是加載單個(gè)HTML 頁(yè)面并在用戶與應(yīng)用程序交互時(shí)動(dòng)態(tài)更新該頁(yè)面的Web應(yīng)用程序）或者部分內(nèi)容做成SPA，這樣，尤其是移動(dòng)端，可以使體驗(yàn)更接近于原生APP
局部刷新，無(wú)需每次都進(jìn)行完整頁(yè)面請(qǐng)求
懶加載，如在頁(yè)面初始時(shí)只加載可視區(qū)域內(nèi)的數(shù)據(jù)，滾動(dòng)后再加載其它數(shù)據(jù)，可以通過(guò) react-lazyload 實(shí)現(xiàn)
富交互，使用 JS 實(shí)現(xiàn)各種酷炫效果
節(jié)約服務(wù)器成本，省電省錢，JS 支持 CDN 部署，且部署極其簡(jiǎn)單，只需要服務(wù)器支持靜態(tài)文件即可

缺點(diǎn)：

前端響應(yīng)較慢，如果是客戶端渲染，前端還要進(jìn)行拼接字符串的過(guò)程，需要耗費(fèi)額外的時(shí)間，不如服務(wù)器端渲染速度快
不利于SEO，目前比如百度、谷歌的爬蟲對(duì)于SPA都是不認(rèn)的，只是記錄了一個(gè)頁(yè)面，所以SEO很差

為什么前端渲染不利于SEO

如果進(jìn)行了前后端分離，那么前端就是通過(guò)JS來(lái)修改DOM使得HTML拼接完全，然后再顯示，或者是使用SPA，這樣，SEO幾乎沒(méi)有。那么這種情況下如何做SEO優(yōu)化呢？

SEO(Search Engine Optimization)，中文一般譯作：搜索引擎優(yōu)化。SEO是一種通過(guò)了解搜索引擎的運(yùn)作規(guī)則(如何抓取網(wǎng)站頁(yè)面，如何索引以及如何根據(jù)特定的關(guān)鍵字展現(xiàn)搜索結(jié)果排序等)來(lái)調(diào)整網(wǎng)站，以提高該網(wǎng)站在搜索引擎中某些關(guān)鍵詞的搜索結(jié)果排名

前面我們談到的SPA不利于SEO，因?yàn)榫湍壳岸?，部分搜索引擎如Google、bing等，它們的爬蟲雖然已經(jīng)支持執(zhí)行JS甚至是通過(guò)AJAX獲取數(shù)據(jù)了，但是對(duì)于異步數(shù)據(jù)的支持也還不足。


因?yàn)閱雾?yè)面的情況下的頁(yè)面中的很多內(nèi)容都是根據(jù)匹配到的路由動(dòng)態(tài)生成并展示出來(lái)的，而且很多頁(yè)面內(nèi)容是通過(guò)ajax異步獲取的，網(wǎng)絡(luò)抓取工具并不會(huì)等待異步請(qǐng)求完成后再行抓取頁(yè)面內(nèi)容，對(duì)于網(wǎng)絡(luò)抓取工來(lái)說(shuō)去準(zhǔn)確模擬相關(guān)的行為獲取復(fù)合數(shù)據(jù)是很困難的，它們更擅長(zhǎng)對(duì)靜態(tài)資源的抓取和分析。