主流JavaScript MVC框架性能比較測試：Angular vs Backbone vs Ember

注* 很多人對AngularJS框架的性能 有所懷疑，尤其是移動端的性能，此文為對目前主流前端MVC框架的評測比較。

在 Filament集團，我們一直非常專注于網站性能。我們一直對主流的的JavaScript MVC框架，如Angular，Backbone和Ember的性能很好奇，主要是因為它們能夠優雅地解決復雜的問題，我們希望能夠使用他們為我們的客戶 服務。使用這些框架來保證性能和提高開發速度，但下載、解析和執行JavaScript是一個相當大的性能瓶頸，特別是當JavaScript用于產生該 站點的HTML內容時。

作為業內人士，我們都知道網站的頁面加載速度（PLT時間），是評價性能的關鍵指標。在一項 研究中 ，47％的用戶，希望網頁在兩秒鐘內加載完成，57％的用戶表示，他們會放棄需要3秒以上時間加載的網頁。谷歌甚至將網頁的加載速度作為其 搜索排名的一個因素。 

在一個快速可靠的無線網絡中，頁面等待的時間往往非常短。但瀏覽器端的用戶到底關心什么？

統計數據顯示（來自GSMA），只有20％的北美客戶有LTE（4G）功能的手機。從全球來看，LTE普及率約為5％。 3G網絡仍是常態，

不過移動設備往往在解析和執行的JavaScript方面非常緩慢。谷歌甚至建議我們,網站應該在一秒鐘內呈現：這些流行的MVC框架能夠提供嗎？

最小的硬件或網絡的需求，就能迅速地呈現頁面是良好設計體現的一個方面。當然，最初的加載時間（您第一次訪問一個網站時所需要的加載時間）可以說是更重要的，特別是在通過社交媒體共享鏈接的時代：沒有一個成功的初次訪問，就沒有后續的訪問。

我們想要找到一種比較方法，不僅僅是看的文件大小來評價這些框架的初始加載時間。

幸運的是， TodoMVC項目具有完全相同的測試用例，基于大范圍流行的JavaScript MVC框架實現。這為我們提供了一個級小的，測試應用程序：沒有第二次加載，資源很小和最少的邏輯。

該TodoMVC的例子不是“生產環境”下的，因為他們只是為了表現同一個應用在不同框架下是如何構建的。為了接近一個真實的生產環境中，我們修改了TodoMVC代碼示例，將文件壓縮合并與最小化(minification)，以及將服務器遷到接近測試地點的一個地方。

我們跑了一下 WebPageTest.org 和  Andy Davies的 批量測試的表格。 我們做了20次瀏覽器連接的測試，去除極端值。我們測試了有線連接下的桌面瀏覽器（Chrome瀏覽器）和移動瀏覽器（Android的瀏覽器），無論是 在3G和桌面環境下。兩個桌面版本讓我們有機會看到的相同的瀏覽器受不同的網絡狀況的影響; Nexus 5個給了我們一個現代3G Android手機具有的連接體驗。

采集了 所有的數字，我們最感興趣的渲染開始了。下圖為Todo應用程序的UI首次出現的WebPageTest所需時間。這也是一個用戶可以最早使用的點。換句 話說，渲染開始時間之前，訪客會一直盯著一個空白屏幕。下圖為 Ember,在 Nexus 5 手機的 3G:環境下的模擬視圖：

弄清楚什么可以測什么不能測非常重要。

首 先，這些試驗的目的是為每個框架建立一個合理體現渲染時間的“最佳情況”，在三種不同的網絡/設備條件下進行測試。Chrome（我們用于測試的瀏覽 器），是世界上最快，最符合標準的瀏覽器之一，還有一個非常簡單的TodoMVC的功能，它不太可能有更豐富的功能。所以，如果這里的結果看起來比較慢， 那么更復雜的應用程序可能會更慢。

其次，這些測試不是渲染架構之間的啟動時間進行了比較。使用一個應用程序給定的框架測出的低渲染時間，并不意味著該框架建立的所有應用程序渲染的都比較快。例如，它可能是通過利用在Angular和Ember的復雜性抽象，降低整體代碼大小。

通過檢查 這些數據，它呈現出幾下：

Ember在Nexus5的3G環境下需要約5秒鐘，桌面Chrome在3G下平均需要3秒。

Angular在Nexus5的3G環境下平均需要4秒，3G桌面瀏覽器需要3秒左右。

Backbone似乎在所有連接下的性能都是最好的。

看的Nexus5和桌面程序在同樣的3G網絡下的差異表明，Angular和Ember初始頁面渲染對機器性能有較高的要求。

平均初的渲染時間：

我們鼓勵你看看測試代碼和數據然后自己做出判斷。不過要強調的是，如果你只看重頁面加載時間，那么現在的很多工具可能都不能用了。

但是，我們有理由相信，這一點在將來肯定會有所提高。

原文地址： filamentgroup.com