談談前端渲染 VS 後端渲染
看看下面的測試時間,單位: ms
模板字串:
var s = '{{#datas}}{{name}} abcdefg {{type}} {{date}}{{/datas}}';
資料物件: 放入100000行資料
var stack = []; for (var i = 0; i < 100000; i++) { stack.push({ name: 'name-' + i, type: 'type-' + i, date: (new Date()).toLocaleString() }); } var datas = {datas: stack};
後端渲染: 生成HTML
var start = Date.now();
require('hogan').compile(s).render(datas);
var end = Date.now();
console.log(end - start); // 166 ms 我的機器時間
前端渲染: 我在這裡做了最簡單的設定,只把datas轉化成字串
var start = Date.now();
JSON.stringify(datas);
var end = Date.now();
console.log(end - start); // 450 ms 我的機器時間
結果對比一目瞭然,你可以把這個測試用其他模板引擎測試一下。
#伺服器為了前端渲染,對物件的字串化所消耗的時間, 遠遠大於 伺服器直接渲染模板生成HTML所花費的時間。
我的建議是前後端模板同時使用.
後端模板+Bigpipe處理頁面載入, 加上預編譯, 這要比直接轉換物件=>字串快, 而且減少前端模板檔案的載入量 res.write(require(‘hogan’).compile(s).render(datas)) 要比
res.write(JSON.stringify(datas))快
前端模板, 主要是部分需要ajax載入的部件
剩下一個最難對付的就是SEO,對於不支援js的機器人,還是需要額外的一套非模板的程式碼.
這個問題的焦點並不在“放在哪裡渲染快”,如果你要考慮這個效率問題,那是不是也得同時思考下:
後端渲染完了之後,需要進行網路傳輸的體積大了,帶來的網路損耗和網路傳輸時間問題
很多場景,尤其是在移動端,我們通常不會把渲染工作交給後端,一方面後端渲染需要時間,一方面龐大的渲染資料傳輸也有時延,所以就會出現白屏問題。Bigpipe可以一定程度上處理這個問題,不夠構架成本略高,用的人偏少。 若把資料交給前端渲染,也存在一定的弊端,比如需求發生變化之後,介面需要調整,前端模板的解析也要跟著一起變化,這樣隔著一層介面開發,辦事效率就低了很多,因為我們至少要跟開發同學交涉。
nodejs 的出現讓模板複用方便了不少,很多時候,讓後端渲染一部分(比如首屏部分),後面的工作就交給前端非同步去處理。兩者結合起來效果才是最佳的。
#SEO問題嘛,看產品需求,很多產品優化了 SEO 也沒多大作用,如果實在要考慮:
1.可以使用 pjax / quickling / hash bang 等技術
2.伺服器端根據 UA 輸出內容
不能簡單這麼比吧,你這個測試只說明V8在你伺服器環境上單次執行這個渲染的速度比PC快,但要知道伺服器可是每個請求都執行渲染,影響的是全部使用者,而前端渲染隻影響單機。 所以“後端吐首屏+前端渲染剩下的”是比較合適的辦法。
移動端,如果不是webapp,只需要傳送資料就可以了.安卓和ios客戶端自己管理渲染.
對於PC端HTML內容的渲染,我還是比較建議Bigpipe推.
#如果是採用ajax拉,那麼頁面上每一個部件要多增加一個客戶端請求. 而請求帶來的請求體解析,本身是十分消耗伺服器資源的.
比如一個網頁有3個部分,來自3個數據庫請求:
[使用者賬單]
[使用者訊息]
[使用者文章]
如果是Bigpipe, 過程是這樣的:
客戶端請求
伺服器傳送佈局HTML
伺服器傳送渲染過的
伺服器傳送HTML結束標籤
只有1次伺服器請求
#如果是前端ajax渲染, 過程是這樣的:
客戶端請求
傳送完整HTML佈局頁
客戶端使用者賬單ajax請求
客戶端使用者訊息ajax請求
客戶端使用者文章ajax請求
伺服器傳送使用者賬單資料
伺服器傳送使用者訊息資料
伺服器傳送使用者文章資料
這個過程需要4次客戶端請求. 就算是把後3個ajax合併為一個ajax,也需要2個客戶端請求.
#瀏覽器端渲染優點:
分散服務端渲染時間到瀏覽器端
http response 大小也會減少
對可維護性也有很大好處
很容易搭建 前端獨立的開發環境
減少了模板修改跟後端同步的問題
缺點就是:
seo
首屏會有白屏
最頭疼的一個問題可能是 業務邏輯的問題,因為很容易業務邏輯就跑到 js 來了
前端渲染的方式的話我覺得不一定是 bigpipe ,還要看場景;
#對移動端上我覺得還是後端渲染好些,因為移動端上 cpu 還是要差些的,放到瀏覽器端渲染可能白屏時間更長一些
這裡推薦一下我的前端學習交流群:784783012,裡面都是學習前端的,如果你想製作酷炫的網頁,想學習程式設計。自己整理了一份2018最全面前端學習資料,從最基礎的HTML+CSS+JS【炫酷特效,遊戲,外掛封裝,設計模式】到移動端HTML5的專案實戰的學習資料都有整理,送給每一位前端小夥伴,有想學習web前端的,或是轉行,或是大學生,還有工作中想提升自己能力的,正在學習的小夥伴歡迎加入學習。
點選:加入
相關推薦
談談前端渲染 VS 後端渲染
看看下面的測試時間,單位: ms 模板字串: var s = '{{#datas}}{{name}} abcdefg {{type}} {{date}}{{/datas}}'; 資料物件: 放入100000行資料 var stack = []; for (va
淺析前端渲染與後端渲染
前端渲染與後端渲染本質上可以理解為:瀏覽器渲染與伺服器渲染 備註:以下純屬本人個人的一些總結與看法,如有異同,歡迎大家指教; 渲染的本質:字串的拼接,將資料渲染進固定格式的html程式碼中,形成最終的html顯示在使用者頁面上。 對比:
前端路由和後端路由,前端渲染和後端渲染
1.vue-router和koa-router的區別 vue-router是前端路由,koa-router是後端路由。 前端路由 定義:在單頁面應用,大部分頁面結構不變,只改變部分內容的使用 優點:使用者體驗好,不需要每次都從伺服器全部獲取,快速展現給使用者 缺點: 使用瀏覽器的
前端渲染與後端渲染的區別
前端渲染: 指的是後端返回JSON資料,前端利用預先寫的html模板,迴圈讀取JSON資料,拼接字串(es6的模板字串特性大大減少了拼接字串的的成本),並插入頁面。 好處:網路傳輸資料量小。不佔
前端渲染和後端渲染,要說的都在這裡?
時下,前端 UI 設計越來越複雜,可謂“XX與XX齊飛,XX共XX一色”。 越來越複雜的 UI 意味著越來越重的 渲染工作。 目前通常有兩種選擇:伺服器渲染 與 客戶端渲染 筆者是支援客戶端渲染的(沒錯就是欽點的) 以 Jade, YAML 為代表的 模板渲
前端渲染與後端渲染
前端渲染 指的是後端返回json資料,前端利用預先寫的html模板,迴圈讀取json資料,拼接字串,並插入頁面。 好處:網路傳輸資料量小 壞處:前端耗時較多 後端渲染 指的是後端返回html片段,前端接受到資料之後,直接插入頁面。 好處:前端耗時少 壞處:網路
前後端分離:前端人員做頁面與渲染,後端做介面
用到的技術: 1.nginx 關鍵,反向代理請求 2.Ajax 請求介面載入內容 3.Json 4.AngularJS 模組化開發,非必要 流程 Nginx 關鍵配置 location /lorenzo/api {
後端渲染和前端渲染的比較
脫離場景談架構都是耍牛氓!不同的方案會有不同的優劣,我們來比較一下後端模板渲染和前端模板渲染:一、後端渲染頁面呈現速度:快,受限於使用者的頻寬流量消耗:少一點點(可以省去前端框架部分的程式碼)可維護性:差(前後端東西放一起,掐架多年,早就在鬧分手啦)seo友好度:好編碼效率
細說後端模板渲染、客戶端渲染、node 中間層、伺服器端渲染(ssr)
前端與後端渲染方式的發展大致經歷了這樣幾個階段:後端模板渲染、客戶端渲染、node 中間層、伺服器端渲染(ssr)。 1. 後端模板渲染 前端與後端最初的渲染方式是後端模板渲染,就是由後端使用模板引擎渲染好 html 後,返回給前端,前端再用 js 去操作 dom 或者渲染其他動態的部分。 這個過程大致分成以
細說後端模板渲染、客戶端渲染、node 中間層、服務器端渲染(ssr)
並且 git 開發效率 代碼 情況下 引擎 fin ive bubuko 細說後端模板渲染、客戶端渲染、node 中間層、服務器端渲染(ssr) 前端與後端渲染方式的發展大致經歷了這樣幾個階段:後端模板渲染、客戶端渲染、node 中間層、服務器端渲染(ssr)。 1. 後端
webpack生成html檔案,用於後端渲染的研究
不適用後端渲染的原因 webpack的打包方式是把所有的資源都打包成bundle.js,並用一個沒有內容的html引入生成的bundle.js,不太熟悉的同學可以參看慕課網的視訊教程。但是如果公司的建站方式是後端渲染的話(如jsp),那就不能使用webpack
一步步從後端渲染到前後端分離經驗分享(1)
概念普及 後端渲染 後端採用JSP,freemarker,jdea,babel等渲染框架對前端模板進行預編譯。 假設有這麼一組資料你想展示在介面上: name MrXu MrXu0 MrXu1 <
關於後端渲染html頁面給遊覽器
class IndexHandler(tornado.web.RequestHandler): def get(self): self.render('index.html') if __name__ == '__main__':
掘金陰明:後端渲染實踐
Vue.js、React.js 及 Angular.js 等等前端開發框架引入了 UI = framework(State) 的前端程式設計邏輯,大範圍降低了前端業務開發的難度,尤其是面向複雜前端應用。而這些優質開源框架的普及、多端業務統一、前後端分離的需求讓越
【Webpack】之 配合後端渲染
為什麼學習Webpack? 對之前開發形式的厭煩,想打破 更好模組管理 安全,對檔案壓縮,使外者不易看出 減少重複工作 程式碼分割 分離業務程式碼
JavaScript前端和Java後端的AES加密和解密
proto creat eight prop pen 保持 超出範圍 system creator 在實際開發項目中,有些數據在前後端的傳輸過程中需要進行加密,那就需要保證前端和後端的加解密需要統一。這裏給大家簡單演示AES在JavaScript前端和Java後端是如何實現
前端基於react,後端基於.net core2.0的開發之路(1) 介紹
tco ioc logs asp webpack 路由 src 部署 關鍵字 文章提綱目錄 1.前端基於react,後端基於.net core2.0的開發之路(1) 介紹 2.前端基於react,後端基於.net core2.0的開發之路(2) 開發環境的配置,
4.前端基於react,後端基於.net core2.0的開發之路(4) 前端打包,編譯,路由,模型,服務
hub 解決 路徑 export routes run 部署 service 後端 1.簡要的介紹 學習react,首先學習的就是javascript,然後ES6,接著是jsx,通常來說如果有javascript的基礎,上手非常快,但是真正要搭建一個前端工程化項目,還是有很
前端基於react,後端基於.net core2.0的開發之路(番外篇) 後端使用T4模板,生成某些類
bsp 。。 bubuko 按鈕 uil out eva 下載地址 所有 1.介紹 因為開發過程中,有部分類是你加一個模型,就需要去改動的,每次加非常的煩,或者有些類,你只用到了他基類的方法,但是你還必須建一個文件才能調用他基類的方法,也很煩。 這個時候,T4就非常有用了。
基於C# 的RSA 前端JS加密後端進行解密。
logs key 網絡 base64 text message 進制 rtp pts 前端代碼 引用 js : http://passport.cnblogs.com/scripts/jsencrypt.min.js通過接口從服務端獲取隨機一對密鑰串,主鍵為Token