摘要:避免這種情況的出現,可以參考對比優化的效果中存在兩種狀態,優化和非優化可以看到優化的狀態,和的時間都大大減少了所以明顯提高性能優化的知識儲備使用模型測量性能基礎儲備渲染性能概述的剖析
一,初探,根據現象發現問題chrome的performance知道很久了,但總是沒有特別權威且跟上時代的學習資料,這次痛定思痛,直接看英文文檔,一點點把這塊啃掉,本筆記基于Chrome 59
目的是避免緩存以及不必要的問題
谷歌性能測試地址googlechrome.github.io/devtools-sa…
可以看到如下的頁面:
由于有些用戶的設備cpu性能很高,無法很好的分析移動端,或者發現低級設備的性能問題,所以我們要降速
找到控制臺中的performance項,找到CPU選項,選擇降低4倍性能或6倍性能
前面限制了cpu的性能,接下來就要找到性能瓶頸了
連續點擊Add 10按鈕,向頁面中添加小塊,直到自己都感覺頁面上小塊運動出現明顯卡頓
點擊一下Optimize優化,觀察一下效果
再點擊一次Un-Optimize(不優化)按鈕,可以看到又卡的要死
如何分析現象,肯定要依賴數據,這里就要用到chrome的performance功能了
先將頁面切到非優化的狀態,點擊“錄制”按鈕
錄制4s-5s即可:
然后就可以看到錄制的效果了:
fps:是指頁面每秒幀數
fps = 60 性能極佳
fps < 24 會讓用戶感覺到卡頓,因為人眼的識別主要是24幀
此時切換優化狀態,到已優化的狀態,再次進行性能錄制:
可以看到此時:
1,沒有了紅色條
2,綠色半透明條的高度,明顯要比未優化的場景高度要高不少
總結:
紅色:意味著幀數已經下降到影響用戶體驗的程度,chrome已經幫你標注了,這塊有問題
綠色:其實就是Fps指數,所有綠色柱體高度越高,性能越好
上圖中Fps下面的位置,即是Cpu信息
我們再采集一個真實業務的cpu數據,如下圖:
對比可以發現,cpu數據的一些特性:
1,cpu包括兩種狀態:
(1)充滿顏色
(2)不充滿顏色
2,cpu是否充滿顏色和fps存在聯系
Net部分可以將屏幕逐幀錄制下來,可以幫助觀察頁面的狀態,主要用處,可以幫助分析首屏渲染速度
Frames部分,主要用于查看特定幀的fps,可以查看特定的幀情況。
可以看到:
這一幀的時間間隔是129.1ms
當前的fps是1000ms/129.1ms = 7.75fps,約等于8fps
這里主要體現的是頁面兩次刷新之間間隔了129.1ms
點擊Frames可以顯示當前關鍵幀的詳細信息:
1,duration是當前幀從796.31ms開始等待,796.31ms+127.73ms后進行了一次渲染
2,fps還是老算法,1000ms/127.73ms約等于7fps
3,最下面是關鍵幀的視圖畫像
這個東西,暫時先關閉,不利于系統性的學習
三,找到瓶頸
前面已經知道我們的測試頁面有性能問題,那么接下來就要想為什么了?
對性能進行錄制完成的時候,會默認在底部展示一個Summary摘要,顯示全局的信息
上面展示了0~5.52s錄制時間的具體耗時:
1,script執行耗時1952.8ms
2,render渲染耗時2986.8ms
3,Painting重繪耗時472.1ms
主要就是這3個耗時,知道了這三部分耗時,只是知道了,哪有問題,但具體問題在哪呢?
上圖,紅色邊框圈出來的,就是Main部分,其中每一塊是每一幀中所做的事情
目前這樣看不出來什么,腦殼疼,為了方便我們觀看,我們可以在fps、cpu、net模塊,點擊一下,縮小時間區間
火焰圖,可以簡單理解,x軸表示時間,y軸表示調用的函數,函數中還包含依次調用的函數,y軸只占用x軸的一個時間維度
上圖中,可以看到Animation Frame Fired右上角有個紅色三角號,這就是chrome自動幫助識別出有問題的部分
就像FPS中的紅條一樣,用來識別問題
上圖可以看到提示了Warning : 重復處理程序耗時287.77毫秒
如上圖,可以看到函數調用在代碼中的位置,可以點擊進行查看
繼續查看Main,可以看到app.update下面有很多紫色的條,紫色條本身表示渲染
但請注意!!! 紫色條上還有更小的
運用前面學過放大功能,調整時間區間
可以看到,每個小紫條上,都有一個紅色三角
前面提到:紅色三角就是chrome幫助自動識別有問題的地方
查看提示信息:強制回流可能是性能瓶頸
點擊查看摘要:
可以看到問題定位在了,app.js的71行,點擊查看,能夠看到是對每一個元素進行樣式修改
此代碼的問題在于,在每個動畫幀中,它會更改每個方塊的樣式,然后查詢頁面上每個方塊的位置。由于樣式發生了變化,瀏覽器不知道每個方塊的位置是否發生了變化,因此必須重新布局方塊以計算其位置。
避免這種情況的出現,可以參考developers.google.com/web/fundame…
demo中存在兩種狀態,優化和非優化
可以看到優化的狀態,script和render的時間都大大減少了
所以fps明顯提高
step 7:性能優化的知識儲備
使用rail模型測量性能developers.google.com/web/fundame…
基礎儲備:
渲染性能概述developers.google.com/web/fundame…
A Frame 的剖析aerotwist.com/blog/the-an…
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/6811.html
摘要:分析每一秒的幀是用來分析動畫的一個主要性能指標。軸代表了調用棧。在事件長條的右上角出,如果出現了紅色小三角,說明這個事件是存在問題的,需要特別注意。雙擊這個帶有紅色小三角的的事件。 運行時性能表現(runtime performance)指的是當你的頁面在瀏覽器運行時的性能表現,而不是在下載頁面的時候的表現。這篇指南將會告訴你怎么用Chrome DevTools Performance...
摘要:原文地址開始在本教程中,你將學會如何使用性能分析工具分析頁面上的性能瓶頸。其中包含了捕獲性能指標相關的設置。參考分析優化版的性能使用剛剛學習的工作流和工具,單擊演示中的優化以啟用優化的代碼,進行另一次性能記錄,然后分析結果。 原文地址:https://developers.google.com... 開始 在本教程中,你將學會如何使用性能分析工具分析頁面上的性能瓶頸。 在隱身模式下打...
摘要:啟動性能瓶頸分析與解決方案翻譯自的,從屬于筆者的前端入門與工程實踐。我們必須要清醒地認識到全面評測以挖掘出真正性能瓶頸的重要性。這可能是最佳的方式了,類似于這樣的模式鼓勵基于路由的分組,目前被與廣泛使用。 JavaScript 啟動性能瓶頸分析與解決方案 翻譯自 Addy Osmani 的 JavaScript Start-up Performance,從屬于筆者的Web 前端入門與工...
摘要:如果網頁動畫能夠做到每秒幀,就會跟顯示器同步刷新,達到最佳的視覺效果。下面的一條是,低于這條線,可以達到每秒幀上面的一條是,低于這條線,可以達到每秒次渲染。圖中幀柱的高度表示了該幀的總耗時,幀柱中的顏色分別對應該幀中包含的不停類型的事件。 原文地址:http://horve.github.io/2015/10/26/timeli... 隨著webpage可以承載的表現形式更加多樣化,通...
摘要:因此,如果可能,最好利用好毫秒響應預先計算開銷大的工作,這樣網站就更有可能實現的性能。空閑主線程工作分成不大于毫秒的塊。點擊按鈕見圖示,會在頁面運行時捕獲性能指標。 前言 經常能在博客或者論壇上看到很多有關前端性能優化的文章,但是卻很少看到如何分析一個網頁的性能的文章。到底什么樣的指標(或者說是標準)代表這個網頁性能好或者不好,通過什么方式來得到這些指標呢?因此,本文來講述下如何分析一...
閱讀 863·2021-10-11 10:59
閱讀 2798·2019-08-30 15:43
閱讀 2132·2019-08-30 11:08
閱讀 1653·2019-08-29 15:20
閱讀 1007·2019-08-29 13:53
閱讀 489·2019-08-26 13:24
閱讀 1636·2019-08-26 13:24
閱讀 2824·2019-08-26 12:08