后端渲染

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

前端渲染

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

前端渲染路線

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

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

后端渲染路線

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

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

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

SPA

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

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

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

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

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

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

SSR

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

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

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

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

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

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

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

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



缺點(diǎn)：

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

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

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

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

缺點(diǎn)：

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

為什么前端渲染不利于SEO

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

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

前面我們談到的SPA不利于SEO，因?yàn)榫湍壳岸裕糠炙阉饕嫒鏕oogle、bing等，它們的爬蟲雖然已經(jīng)支持執(zhí)行JS甚至是通過AJAX獲取數(shù)據(jù)了，但是對于異步數(shù)據(jù)的支持也還不足。


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