單頁web應用如何作性能檢測？

01-26

目前越來越多的場景會採用web技術開發富交互的單頁應用，這樣傳統統計頁面載入速度的工具往往就不再適用了，頁面切換的過程中，往往script計算反而會佔用大量的時間，尤其是頁面上有長列表、樹結構等量較大或較複雜的結構時尤為明顯。如何去統計這類應用的性能指標？是否有比較好的工具推薦？
編輯：看了回復，不少朋友提到了devtool，devtool只能看自己機器的表現，而不是用戶使用中的實際表現，而且開devtool本身就是很耗性能的事情，跟實際使用有較大的差距。

Chrome 調試工具的 timeline tab 就是為具體的性能調試設計的，去英文網站了解下怎樣使用。

再更新一點吧

~~~~

直接上代碼吧

chrome.loadTimes()

{ "requestTime": 0, "startLoadTime": 1464328264.201576, "commitLoadTime": 1464328264.852576, "finishDocumentLoadTime": 1464328265.630576, "finishLoadTime": 1464328269.428576, "firstPaintTime": 1464328265.766576, "firstPaintAfterLoadTime": 1464328269.450576, "navigationType": "Other", "wasFetchedViaSpdy": false, "wasNpnNegotiated": true, "npnNegotiatedProtocol": "http/1.1", "wasAlternateProtocolAvailable": false, "connectionInfo": "http/1" }

2. window.performance

// window.performance.memory


{

    totalJSHeapSize: 23100000,

    usedJSHeapSize: 14300000,

    jsHeapSizeLimit: 793000000

}

// window.performance.timing { "navigationStart": 1464496735968, "unloadEventStart": 1464496736505, "unloadEventEnd": 1464496736505, "redirectStart": 0, "redirectEnd": 0, "fetchStart": 1464496735968, "domainLookupStart": 1464496735968, "domainLookupEnd": 1464496735968, "connectStart": 1464496735968, "connectEnd": 1464496735968, "secureConnectionStart": 0, "requestStart": 1464496735972, "responseStart": 1464496736502, "responseEnd": 1464496736503, "domLoading": 1464496736530, "domInteractive": 1464496737669, "domContentLoadedEventStart": 1464496737669, "domContentLoadedEventEnd": 1464496737718, "domComplete": 1464496738911, "loadEventStart": 1464496738916, "loadEventEnd": 1464496738931 }

終極神器：

console.time("load")

console.timeEnd("load")

感謝shinnyChen的答案，根據stats.js的原理做了web-performance, 以滿足我們的需求，整理一篇文章做一點小小的總結：

對於單頁應用來說，除了首屏載入時間以外，傳統的網頁性能檢測方式已經無法正確的反映網站的性能，因為絕大多數時候，頁面並沒有執行載入動作。單頁應用更多的性能問題往往來自於腳本的運算，大數據的渲染等方面。那麼對於單頁應用如何進行性能檢測呢？

主要指標

運行時間（檢查是否有長時間的腳本執行or渲染）
內存（檢查是否有內存泄露，如果瀏覽器支持performance.memory, 可直接獲取）
FPS （幀數，可通過運行時間進行換算）

方案

console.time()方案：只能針對性的去通過埋點去檢查某些特定的功能，難以在整個應用中大規模的布點.
開發者工具提供的timeline：打開timeline本身對性能有很大影響，得到的數據本身是不準確的，更多的是去看相對值，另外timeline只能本機調試，無法在生產環境中收集數據。
利用JS的單線程特點，通過時間間隔去檢測慢操作：常駐一個timer，可以很方便的搜集線上數據。

綜合來看，第三種方案較為理想，下面我們仔細看一下原理：

原理

如果主線程空閑，timer上配置的回調會在配置的時間間隔後執行，但是如果主線程內有一個執行時間很長的動作，超出了時間間隔，那麼timer回調的執行就會順延，這樣我們就可以通過時間差的計算，發現這些慢操作。

setTimeout or requestAnimationFrame

setTimeout or setInterval有可能會因為強行插入渲染過程而導致掉幀，但好處是時間間隔可以隨意指定， requestAnimationFrame則不會影響渲染，不過時間間隔無法指定，完全由瀏覽器決定，兩種方案各有利弊，可以根據自身的需要靈活選擇

工具

web-performance, 自己做的一個，支持自定義回調
stats.js，原理一樣，有canvas小窗展示，更適合直觀的本地調試。

Performance api，打點也可以。但神器還是工具。看內存佔用 cpu佔用帶寬佔用比如老牌的 dynaTrace Ajax

這個也不錯，JS統計內存、每秒幀數（刷新頻率）。

GitHub - mrdoob/stats.js: JavaScript Performance Monitor

最近在專註做前端。我可能給你無法推薦測試工具，我只想說說我關於web應該性能的理解。

web頁面是離用戶最近的東西，用戶的第一感覺。

所有，第一感覺是很重要的，所以QQ空間才買皮膚。有了臉面後就是你提到的交互了。

現在越來越多應用將交互、數據處理等放到前端了，有區別於之前的富客戶端。

在交互層談性能，必須有一定的條件，比如網路，瀏覽器、機器內存等。

拿你說的長列表來說，不管數據載入方式如何，以你要給用戶展示的形式下，體驗最優為主，比如不卡動、不出現頁面載入等待等。

統計性能指標，方式很多，比如：在帶寬多少的情況下，頁面完全render得多久，每種瀏覽器的響應時間等。