1、為什么會有服務(wù)器渲染與客戶端渲染？

?　　首先理解服務(wù)器和瀏覽器客戶端之間傳遞的是什么——HTML，CSS，JavaScript的文件以及數(shù)據(jù)載體json(xml)等文件，而文件都是靜態(tài)，之所以動態(tài)是應(yīng)為瀏覽器運行腳本之后產(chǎn)生的動態(tài)。這也是為什么JavaScript是腳本語言。

　　一開始，Web App 直接由若干 HTML，CSS， JS 組成，每一個頁面需要特殊的邏輯，因此隨著App規(guī)模的擴大，后端網(wǎng)站目錄下的代碼文件就越來越多，而且，彼此之間是沒有同步的，比如你改了站點的布局風格。那么你很可能需要改動成百上千的HTML文件，這誰能忍?

　　聰明的工程師們想到，既然如此多的HTML具有一定的邏輯聯(lián)系，何不使用代碼生成代碼？于是后端模板語言誕生了，這可是前端狗的一大痛點啊，于是人們開始廣泛使用模板語言代替手寫HTML。我認為，模板語言的成功源于它成功地減少了前端工程師的工作量。

　　后端模板渲染的思路應(yīng)該是源自“如何管理數(shù)以千計的存儲于后端的前端頁面的版本一致？”這個問題的。通過代碼生成代碼，本質(zhì)上是編譯，他們基于HTML等基礎(chǔ)語言作了更高層次的抽象封裝，增強了易用性。各種模板語言大同小異，但大多都有模板中的模板這樣的性質(zhì)來完成繼承這樣的面向?qū)ο筇匦?#xff0c;用后端的思想來說，返回的頁面中其實每個頁面都是大同小異，其中只是html 發(fā)生少許變化，因此將頁面抽象 ，根據(jù)業(yè)務(wù)數(shù)據(jù)渲染出不同特性的新的html返回瀏覽器。

　　當時工程師們沒有考慮前端渲染的一大原因是 以JavaScript為代表的前端技術(shù)尚未崛起。后面隨著谷歌 Google V8 引擎發(fā)布， JavaScript隨之崛起 前端工程師們也開始考慮借鑒后端模板的思想，引入模板概念，也是后面各大框架中的組件(Component)?。減少向服務(wù)器請求重復的頁面，特別是在Node.js出現(xiàn)以后 JS 工程師維護后端的成本大大降低。在這之中興起了Angular，React，Vue ，他們對自己在Web App 的定位也不一樣。?具體情況可以自己去了解，這并不是本文的重點。

2、瀏覽器渲染和服務(wù)器渲染路線

　互聯(lián)網(wǎng)早期，用戶使用瀏覽器瀏覽的都是一些沒有復雜邏輯的、簡單的頁面，這些頁面都是在后端將html拼接好的然后將之返回給前端完整的html文件，瀏覽器拿到這個html文件之后就可以直接解析展示了，而這也就是所謂的服務(wù)器端渲染了。而隨著前端頁面的復雜性提高，前端就不僅僅是普通的頁面展示了，而可能添加了更多功能性的組件，復雜性更大，另外，彼時ajax的興起，使得業(yè)界就開始推崇前后端分離的開發(fā)模式，即后端不提供完整的html頁面，而是提供一些api使得前端可以獲取到j(luò)son數(shù)據(jù)，然后前端拿到j(luò)son數(shù)據(jù)之后再在前端進行html頁面的拼接，然后展示在瀏覽器上，這就是所謂的客戶端渲染了，這樣前端就可以專注UI的開發(fā)，后端專注于邏輯的開發(fā)。

　　客戶端渲染和服務(wù)器端渲染的最重要的區(qū)別就是究竟是誰來完成html文件的完整拼接，如果是在服務(wù)器端完成的，然后返回給客戶端，就是服務(wù)器端渲染，而如果是前端做了更多的工作完成了html的拼接，則就是客戶端渲染。

客戶端渲染路線：

　　1. 請求一個html -> 2. 服務(wù)端返回一個html -> 3. 瀏覽器下載html里面的js/css文件 -> 4.?等待js文件下載完成 -> 5. 等待js加載并初始化完成 -> 6. js代碼終于可以運行，由js代碼向后端請求數(shù)據(jù)( ajax/fetch ) -> 7. 等待后端數(shù)據(jù)返回 -> 8. 客戶端從無到完整地，把數(shù)據(jù)渲染為響應(yīng)頁面

服務(wù)端渲染路線：

　　1. 請求一個html -> 2. 服務(wù)端請求數(shù)據(jù)( 內(nèi)網(wǎng)請求快 ) -> 3. 服務(wù)器初始渲染（服務(wù)端性能好，較快） -> 4. 服務(wù)端返回已經(jīng)有正確內(nèi)容的頁面 -> 5. 客戶端請求js/css文件 -> 6.?等待js文件下載完成 -> 7.?等待js加載并初始化完成 -> 8. 客戶端把剩下一部分渲染完成( 內(nèi)容小，渲染快 )

3、從 后端渲染到前端渲染，發(fā)生了什么變化？

• 計算任務(wù)轉(zhuǎn)移?

　　原本由服務(wù)器執(zhí)行的渲染任務(wù)轉(zhuǎn)移給了客戶端，這在大量用戶訪問的時候大大減輕后端的壓力。讓后端專注做后端應(yīng)該做的事情，性能將大大提高，因為服務(wù)器做的事情確實減小了，而現(xiàn)在隨著客戶端軟硬件的發(fā)展，也能處理好大多數(shù)的渲染工作了。

• 放棄前端權(quán)限?

　　將整個UI邏輯交給客戶端以后，一些有經(jīng)驗有能力的用戶可能會劫持UI，使得他們能夠看到一些不該看到的界面。這似乎違反了安全的原則。但是“一切在前端談安全都是耍流氓”，后端不能輕信一切從前端傳來的數(shù)據(jù)，切記一定要做好過濾與驗證。只要使用SSL、屏蔽XSS、后端不出漏洞，想偽造身份劫持App還是難以做到的。

4、服務(wù)器端渲染的優(yōu)缺點是怎樣的？

• 優(yōu)點：

前端耗時少。因為后端拼接完了html，瀏覽器只需要直接渲染出來。

有利于SEO（搜索引擎優(yōu)化）。因為在后端有完整的html頁面，所以爬蟲更容易爬取獲得信息，更有利于seo。

無需占用客戶端資源。即解析模板的工作完全交由后端來做，客戶端只要解析標準的html頁面即可，這樣對于客戶端的資源占用更少，尤其是移動端，也可以更省電。

后端生成靜態(tài)化文件。即生成緩存片段，這樣就可以減少數(shù)據(jù)庫查詢浪費的時間了，且對于數(shù)據(jù)變化不大的頁面非常高效 。

• 缺點：

不利于前后端分離，開發(fā)效率低。使用服務(wù)器端渲染，則無法進行分工合作，則對于前端復雜度高的項目，不利于項目高效開發(fā)。另外，如果是服務(wù)器端渲染，則前端一般就是寫一個靜態(tài)html文件，然后后端再修改為模板，這樣是非常低效的，并且還常常需要前后端共同完成修改的動作；?或者是前端直接完成html模板，然后交由后端。另外，如果后端改了模板，前端還需要根據(jù)改動的模板再調(diào)節(jié)css，這樣使得前后端聯(lián)調(diào)的時間增加。

占用服務(wù)器端資源。即服務(wù)器端完成html模板的解析，如果請求較多，會對服務(wù)器造成一定的訪問壓力。而如果使用前端渲染，就是把這些解析的壓力分攤了前端，而這里確實完全交給了一個服務(wù)器。

5、客戶端渲染的優(yōu)缺點是怎樣的？

• 優(yōu)點：　　

前后端分離。前端專注于前端UI，后端專注于api開發(fā)，且前端有更多的選擇性，而不需要遵循后端特定的模板。

體驗更好。比如，我們將網(wǎng)站做成單頁Web應(yīng)用（single page web application，SPA，是加載單個HTML?頁面并在用戶與應(yīng)用程序交互時動態(tài)更新該頁面的Web應(yīng)用程序）或者部分內(nèi)容做成SPA，這樣，尤其是移動端，可以使體驗更接近于原生app。

• 缺點：

前端響應(yīng)較慢。如果是客戶端渲染，前端還要進行拼接字符串的過程，需要耗費額外的時間，不如服務(wù)器端渲染速度快。

不利于SEO。目前比如百度、谷歌的爬蟲對于SPA都是不認的，只是記錄了一個頁面，所以SEO很差。因為服務(wù)器端可能沒有保存完整的html，而是前端通過js進行dom的拼接，那么爬蟲無法爬取信息。 除非搜索引擎的SEO可以增加對于JavaScript的爬取能力，這才能保證SEO。

5、使用服務(wù)器端渲染還是客戶端渲染？

　　不談業(yè)務(wù)場景而盲目選擇使用何種渲染方式都是耍流氓。比如企業(yè)級網(wǎng)站，主要功能是展示而沒有復雜的交互，并且需要良好的SEO，則這時我們就需要使用服務(wù)器端渲染；而類似后臺管理頁面，交互性比較強，不需要seo的考慮，那么就可以使用客戶端渲染。

　　另外，具體使用何種渲染方法并不是絕對的，比如現(xiàn)在一些網(wǎng)站采用了首屏服務(wù)器端渲染，即對于用戶最開始打開的那個頁面采用的是服務(wù)器端渲染，這樣就保證了渲染速度，而其他的頁面采用客戶端渲染，這樣就完成了前后端分離。

6、對于前后端分離，如果進行seo優(yōu)化？

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

　　我們可以自行提交sitemap，讓蜘蛛主動去爬取，但是遇到了sitemap中的url，達到指定頁面之后只有元js怎么辦呢？這是我們可以使用<noscript>標簽來進行簡單的優(yōu)化，比如打印出當前頁面信息的一些關(guān)鍵的信息點，但是正常用戶并不需要這些，會造成額外的負擔，且前端可以判斷是否支持JavaScript，而后段不行，只好根據(jù)百度的spider做UA（用戶代理）判斷，使用phantomjs或者nginx代理，來對spider訪問的頁面進行特殊的處理，達到被收錄的效果。但這種效果還是不好。。。

　　而目前的react和vue都提供了SSR，即服務(wù)器端渲染，這也就是提供SEO不好的解決方式了。

7、究竟如何理解前后端分離？

　　實際上，時至今日，前后端分離一定是必然或者趨勢，因為早期在web1.0時代的網(wǎng)頁就是簡單的網(wǎng)頁，而如今的網(wǎng)頁越來越朝向app前進，而前后端分離就是實現(xiàn)app的必然的結(jié)果。所以，我們可以認為html、css、JavaScript組成了這個app，然后瀏覽器作為虛擬機來運行這些程序，即瀏覽器成為了app的運行環(huán)境，成了客戶端，總的來說就是當前的前端越來越朝向桌面應(yīng)用或者說是手機上的app發(fā)展了，而比如說電腦上的qq可以服務(wù)器端渲染嗎？肯定不能！所以前后端分離也就成了必然。而我們目前接觸額前端工程化、編譯（轉(zhuǎn)譯）、各種MVC/MVVM框架、依賴工具、npm、bable、webpack等等看似很新鮮、創(chuàng)新的東西實際上都是傳動桌面開發(fā)所形成的概念，只是近年來前端發(fā)展較快而借鑒過來的。

8、如何理解互聯(lián)網(wǎng)(高并發(fā))的前后端分離？

　　在高并發(fā)下，所有公司的應(yīng)用都會出現(xiàn)并發(fā)瓶頸，筆者所理解的分布離 ，從物理分離，物理分離考慮到服務(wù)器本身磁盤的讀寫有限 ，將前端項目交給I/0處理優(yōu)勢的node 處理 ，前端項目和后端的項目直接在物理機上分離 ，讓node訪問其他物理機的后臺接口，拿到數(shù)據(jù)進行頁面渲染，返回給瀏覽器，node 所在的前端項目 ，完全處理路由 和 權(quán)限資源 ，靜態(tài)資源的分發(fā)，達到真正的分離 ，后端完全無狀態(tài)提供數(shù)據(jù)就行。

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/yuan-jianfeng/p/10790910.html

總結(jié)

以上是生活随笔為你收集整理的前端后分离深入分析 ——浏览器渲染和服务器渲染区别的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。