1、為什麼會有伺服器渲染與客戶端渲染？

　　越來越複雜的 UI 意味著越來越重的渲染工作。目前通常有兩種選擇：伺服器渲染與客戶端渲染。

　　以 Jade, YAML 為代表的模板渲染引擎一般作用於伺服器作為後端的視圖部分。 

　　而使用 JavaScript 直接 處理 HTML DOM 則是 作用於前端，性質是客戶端執行渲染。

　　兩者在最終用戶看到的效果是一致的。 

　　Web App 最終都還是要落實到HTML，CSS，JavaScript上才能體現到用戶界面上。 

　　歸根結底，後端渲染是將一些模板規範語言翻譯成如上三種語言回傳給前端；而前端渲染則是將整個生成邏輯代碼全部回傳前端，再由客戶端生成用戶界面。

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

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

　　後端模板渲染的思路應該是源自“如何管理數以千計的存儲於後端的前端頁面的版本一致？”這個問題的。通過代碼生成代碼，本質上是編譯，他們基於HTML等基礎語言作了更高層次的抽象封裝，增強了易用性。各種模板語言大同小異，但大多都有模板中的模板這樣的性質來完成繼承這樣的面向對象特性。

　　可能，當時工程師們沒有考慮前端渲染的一大原因是 以JavaScript為代表的前端技術尚未崛起。現在HTML5，CSS3，JS 受到越來越廣的普及使得前端的可作為性大大提升，特別是在Node.js出現以後 JS 工程師維護後端的成本大大降低。

在一些jQuery用戶的角度看來，JS生成前端無非就是這樣的

　　var e = document.createElement('div');
　　$('#container').append(e);

　　你需要先把DOM生成，然後再插入到其他的DOM里去。純JS處理DOM確實是一件麻煩事，這可能也是客戶端渲染遲遲沒有發展起來的原因之一。

　　考慮一下為什麼後端模板語言方便簡潔？ 因為它用了與HTML類似的語法。在PHP，JSP頁面裡面你可以使用大量的HTML語法，只使用少量的變數註入與迭代註入。

使用HTML進行設計明顯比純JS更方便快捷並且直觀。

　　那麼可以借鑒地，解決客戶端渲染問題的最後一個錦囊就是引入模板，在這裡我們稱之為組件(Component) 。

　　對待模板，新興的Angular，React，Vue 意見不一，甚至他們對自己在Web App 的定位也不一樣。 具體情況可以自己去瞭解，這並不是本文的重點。

　　隨著前端也支持了模板語言，那麼以前的代碼管理問題也解決了，以往的後端渲染引擎也大多有了基於JS的前端版本。

　　前後端真正解耦，前端將專註於UI，後端將專註於數據處理，兩端通過設計好的API進行交互，這會是一個趨勢。

2、瀏覽器渲染和伺服器渲染路線

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

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

客戶端渲染路線：

　　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. 客戶端把剩下一部分渲染完成( 內容小，渲染快 )

3、從 後端渲染到前端渲染，發生了什麼變化？

• 計算任務轉移 

　　原本由伺服器執行的渲染任務轉移給了客戶端，這在大量用戶訪問的時候大大減輕後端的壓力。讓後端專註做後端應該做的事情，性能將大大提高，因為伺服器做的事情確實減小了，而現在隨著客戶端軟硬體的發展，也能處理好大多數的渲染工作了。

• 放棄前端許可權 

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

4、伺服器端渲染的優缺點是怎樣的？

• 優點：

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

2. 有利於SEO（搜索引擎優化）。因為在後端有完整的html頁面，所以爬蟲更容易爬取獲得信息，更有利於seo。

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

4. 後端生成靜態化文件。即生成緩存片段，這樣就可以減少資料庫查詢浪費的時間了，且對於數據變化不大的頁面非常高效 。

• 缺點：

1. 不利於前後端分離，開發效率低。使用伺服器端渲染，則無法進行分工合作，則對於前端複雜度高的項目，不利於項目高效開發。另外，如果是伺服器端渲染，則前端一般就是寫一個靜態html文件，然後後端再修改為模板，這樣是非常低效的，並且還常常需要前後端共同完成修改的動作； 或者是前端直接完成html模板，然後交由後端。另外，如果後端改了模板，前端還需要根據改動的模板再調節css，這樣使得前後端聯調的時間增加。

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

5、客戶端渲染的優缺點是怎樣的？

• 優點：　　

1. 前後端分離。前端專註於前端UI，後端專註於api開發，且前端有更多的選擇性，而不需要遵循後端特定的模板。

2. 體驗更好。比如，我們將網站做成單頁Web應用（single page web application，SPA，是載入單個HTML 頁面併在用戶與應用程式交互時動態更新該頁面的Web應用程式）或者部分內容做成SPA，這樣，尤其是移動端，可以使體驗更接近於原生app。

• 缺點：

1. 前端響應較慢。如果是客戶端渲染，前端還要進行拼接字元串的過程，需要耗費額外的時間，不如伺服器端渲染速度快。

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

5、使用伺服器端渲染還是客戶端渲染？

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

　　另外，具體使用何種渲染方法並不是絕對的，比如現在一些網站採用了首屏伺服器端渲染，即對於用戶最開始打開的那個頁面採用的是伺服器端渲染，這樣就保證了渲染速度，而其他的頁面採用客戶端渲染，這樣就完成了前後端分離。

6、對於前後端分離，如果進行seo優化？

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

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

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

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

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