關于服務端渲染與客戶端渲染的優劣，互聯網上已經有過很多的文章進行過分析，在這里我談一下我個人的見解。

首先，還是來老生常談一下關于兩種渲染方式的主要優劣：

服務端渲染（僅列出當下最突出的優劣）：

優：

• SEO友好（目前現狀下，我認為是最大的優點，也是最大的需求）
• 首屏渲染速度快（不用下載臃腫的bundle.js）

劣：

• 增加服務器壓力（在訪問量猛增時，這是非常致命的，可能直接導致服務器掛掉）
• 交互方式單一，無法進行異步刷新（可以通過后端在html中插入js代碼綁定事件來實現異步刷新）

客戶端渲染的優劣則與服務端渲染相反。

在十幾年前，那時候javascript還沒有興起，web開發還是使用傳統的ASP、Java、PHP等語言，渲染方式也就局限于服務端渲染。但是隨著jQuery的發展，異步加載技術的成熟，前端所做的事情也就越來越多。隨著一批批前端開發人員對于交互體驗的不斷完善，頁面性能的極致追求，在近幾年不斷涌現出非常優秀的前端框架庫，比如說當下最流行的Angular、React、Vue和處于成長階段的next.js、阿里的beidou框架等。可以說，如今js真可謂是百家爭鳴了。

從一開始后端語言驅動的服務端渲染，到如今React等前端框架引領的客戶端渲染，不管是用戶體驗方面，還是性能方面，都有了一個質的提升。當我們正享受著客戶端渲染帶來的舒適時，一部分互聯網企業又悄悄的變回了服務端渲染，這樣一個逆著發展方向的做法，實屬無奈的選擇，很大一方面是為了應對國內某度尷尬的SEO。為了針對服務端渲染的需求，React還實現了renderToString的方法用來將根據數據生成的dom結構轉成相應字符串，方便由后端輸出給前端。至于Vue和Angular有沒有實現類似的方法還沒有去了解過，用興趣的同學可以去他們的官網查下文檔。

據我所知，Google已經實現了可以通過執行頁面中js代碼的方式來爬取數據，也就是說，Google已經有能力爬取客戶端渲染的頁面了（不是崇洋媚外，確實人家做的比國內好），而國內某度，還停留在爬取html的階段。單純的客戶端渲染，html文件是沒有實質性內容的，所有內容都是通過js異步加載來的，于是某度面對客戶端渲染的頁面，只能兩眼一黑。

不過，國內搜索引擎終究也會實現對客戶端渲染頁面的爬取的，這只是一個時間問題罷了。雖然說在當下，服務端渲染這個最大的優點還是客戶端渲染無法解決的，但是隨著時間的推移，互聯網的進步，這都將不再是問題。

再來說說首屏渲染的問題。用過React或者Vue的同學都知道，打包出來的bundle.js文件大小通常都在1M以上，而這個入口js通常要在渲染首頁之前完全下載完畢，然后再運行其中的js獲取數據、渲染頁面，這是spa頁面加載的一個機制。js的運行、數據的獲取、頁面的渲染這些都是瀏覽器的工作，基于現在的V8引擎，這些步驟都可以很快完成，而這個1M以上甚至更大的入口js的下載就是一個非常大的問題了。如果是pc端，在目前國內正常用戶的網絡環境下，這點大小的文件還不成問題，但如果是移動端，就要好好考慮一下了。在4G網絡環境下，這1M的文件可以說下載起來非常輕松，1秒就可以下載完畢；如果使用3G網絡，則1M大概需要下載4到5秒，這個時間已經影響到用戶體驗了；如果使用2G網絡，或者在信號不好的地方，那這個時間就慘不忍睹了，用戶需要等待漫長的白屏，甚至會造成當前頁面已經打不開了的誤解。

客戶端渲染流程

針對這種網絡狀況不好的情況下，首屏渲染極慢的問題，有人提出了同構的思想。其意為前后端使用同一套代碼，首屏使用服務端渲染，將渲染好的html直接交給瀏覽器去渲染，瀏覽器渲染出首屏之后繼續下載bundle.js，運行js，并且重新渲染頁面。由于渲染好的html流相較于bundle.js來說，體積小了很多，所以采用同構方式的web頁面，一定程度上解決了首屏渲染慢的問題，而且合理利用緩存策略還可以一定程度減輕服務器壓力。當然這種模式當中還存在著其他問題，在這里就不細說了。

同構渲染流程

使用同構這種開發模式，雖然不能完全解決SEO的問題，但是首屏是可以被爬取的，如果說項目不是類似于淘寶這種內容型網站（網站內部各個頁面都有SEO需求），那么這種模式就非常優秀了，解決了純客戶端渲染在當下面臨的兩個最大的問題。

在今年舉辦的第12屆D2前端大會上，筆者又聽到了一個十分優秀的想法，并且阿里已經將之實現并申請了專利————智能降級策略。具體名字是不是這個已經記不太清了，大致內容是在同構的基礎之上，優先使用服務端渲染，當訪問量激增導致服務器負載超過設置的閾值之后，智能將部分渲染任務交給客戶端處理，使服務器承受壓力降低（想想就很厲害啊，畢竟阿里，有錢有人有才）。

毫無疑問，同構或者智能降級在面對當前國內互聯網發展狀況下，是非常有發展空間的。但是如果需要考慮到開發成本和硬件成本，單純的客戶端渲染還是占有優勢的。同構或許是web開發的一個方向，但是絕不僅僅是唯一的一條路，具體采用什么樣的方式構建項目，還是需要根據具體項目的需求來確定。

文中圖片來源于 以同構之名，再談 Redux/Vuex 的必要性

轉載于:https://juejin.im/post/5a4053ca6fb9a04511715927

總結

以上是生活随笔為你收集整理的服务端渲染vs客户端渲染到前后端同构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。