資訊專欄INFORMATION COLUMN
摘要：因此，如果可能，最好利用好毫秒響應預先計算開銷大的工作，這樣網站就更有可能實現的性能。空閑主線程工作分成不大于毫秒的塊。點擊按鈕見圖示，會在頁面運行時捕獲性能指標。
前言
經常能在博客或者論壇上看到很多有關前端性能優化的文章，但是卻很少看到如何分析一個網頁的性能的文章。到底什么樣的指標（或者說是標準）代表這個網頁性能好或者不好，通過什么方式來得到這些指標呢？因此，本文來講述下如何分析一個網頁的性能的好與差。本文用到的工具：chrome瀏覽器。下面我們一一來看。
用RAIL模型評估運行時性能首先要說明的是，運行性能是指你的網頁在運行的時候的性能，而不是加載的時候的性能。RAIL（Response-Animation-Idle-Load）模型是一種以用戶為中心的性能模型，每個網絡應用均具有與其生命周期相關的四個不同方面，且這些方面以不同的方式影響著性能。用官網圖來鎮壓一下：
下面分別從四個方面闡述RAIL模型：
以用戶為中心任何網站的終極目標不是讓其在任何特定設備上都能運行很快，而是讓使用該網站的用戶滿意。用戶花在網站上的大多數時間不是等待加載，而是在使用過程中等待響應。那么怎樣評價延遲？讓我們來看下面的表：
| 延遲 | 用戶反應 |
|---|---|
| 0~16毫秒 | 人們特別擅長跟蹤運動，如果動畫不流暢，他們就會對運動心生反感。 用戶可以感知每秒渲染60幀的平滑動畫轉場，也就是每幀16毫秒（包括瀏覽器將新幀繪制到屏幕上所需的時間），那么，留給應用大約只有10毫秒的時間來生成新幀。 |
| 0~100毫秒 | 在此時間內響應用戶操作，他們會覺得可以立即獲得結果。時間再長，操作與反應之間的連接就會中斷 |
| 100~300毫秒 | 用戶會遇到輕微可覺察的延遲。 |
| 300~1000毫秒 | 在此時間內，延遲感覺像是任務自然和持續發展的一部分。對于網絡上的大多數用戶，加載頁面或更改視圖就像在完成一個任務。 |
| 1000+毫秒 | 超過1秒，用戶的注意力將離開他們正在執行的任務。 |
| 10,000+毫秒 | 用戶感到失望，可能會放棄任務，并且之后他們或許不會再回來。 |
在用戶注意到滯后之前網站有100毫秒的時間可以響應用戶輸入。這適用于大多數輸入，比如點擊按鈕、切換表單控件或是啟動動畫。但是不適用于觸摸拖動或滾動（因為觸摸拖動或滾動屬于動畫范疇）。如果網站未響應，操作與反應之間的連接就會中斷，用戶會注意到。因此，對于需要超過500毫秒才能完成的操作，需要始終提供反饋。
其實，有些動作可以不等到用戶操作了才響應。網站可以使用此100毫秒時間在后臺來執行其他開銷大的工作，但前提是不影響用戶當前的操作。
動畫（Animation）: 在10毫秒內生成一幀（即達到60fps）動畫不止是奇特的UI效果，例如滾動和觸摸拖動也屬于動畫類型。如果動畫幀率發生變化，用戶便會注意到。網站的目標是每秒生成60幀，每一幀必須完成以下所有步驟：
從純粹的數學角度而言，每幀的預算約為16毫秒（1000毫秒/60幀=16.66毫秒/幀）。但將新幀渲染到屏幕上也是需要花費時間的，因此實際上瀏覽器只有10毫秒的時間來執行代碼，如果無法符合此估算，幀率將下降，并且內容會在屏幕上抖動，也就是卡頓，會對用戶體驗產生負面影響。因此，如果可能，最好利用好100毫秒響應預先計算開銷大的工作，這樣網站就更有可能實現60fps的性能。
空閑（Idle）：最大程度增加空閑時間可以利用空閑來完成推遲的工作。例如：盡可能減少預加載的數據，以便網站能夠快速加載，并利用空閑時間加載剩余數據。推遲的工作應分成每個耗時約50毫秒的多個塊。如果用戶開始交互，優先級最高的事項是響應用戶。要實現小于100毫秒的響應，應用必須在每50毫秒內將控制返回給主線程，這樣網站就可以執行其他像素管道、對用戶輸入作出反應等命令。
因此，以50毫秒塊工作既可以完成任務，又能確保即時的響應。
加載（Load）：在1000毫秒以內呈現內容在1秒鐘內加載網站，否則，用戶的注意力會分散，他們處理任務的感覺會中斷。其實也無需在1秒內加載所有內容以讓用戶產生完整加載的感覺。應該啟用漸進式渲染和在后臺執行一些工作，將非必需的加載推遲到空閑時間段再來加載。
關鍵RAIL指標匯總要根據RAIL指標評估您的網站，可使用Chrome的DevTools的performance面板（舊版本chrome可以用TimeLine工具）記錄用戶操作（具體可見下面一節講解如何記錄性能數據）。然后根據這些關鍵RAIL指標檢查面板中的記錄時間。
| RAIL步驟 | 關鍵指標 | 用戶操作 |
|---|---|---|
| 響應 | 輸入延遲時間（從點按到繪制）小于100毫秒。 | 用戶點按按鈕（例如打開導航）。 |
| 動畫 | 每個幀的工作（從JS到繪制）完成時間小于16毫秒。 | 用戶滾動頁面，拖動手指（例如打開菜單）或看到動畫。 拖動時，應用的響應與手指位置有關（例如，拉動刷新、滑動輪播）。 此指標僅適用于拖動的持續階段，不適用于開始階段。 |
| 空閑 | 主線程JS工作分成不大于50毫秒的塊。 | 用戶沒有與頁面交互，但主線程應足夠用于處理下一個用戶輸入。 |
| 加載 | 頁面可以在1000毫秒內就緒。 | 用戶加載頁面并看到關鍵路徑內容。 |
下面的教程指引了如何利用chrome開發車工具(DevTools)的performance面板來分析運行時性能。
準備工作注意：下面的指引基于chrome 62版本，如果你用了其他版本的chrome，其UI界面和特征會有些許的不同。
首先我們打開官網提供的demo,請確保用瀏覽器隱身模式打開，以保證瀏覽器是在一個純凈的環境中。否則，如果你安裝了很多瀏覽器擴展，會對你性能分析的數據產生一定的干擾。接著打開DevTools，具體方法：Command+Option+I (Mac) or Control+Shift+I (Windows, Linux)。
模擬手機CPU手機設備具有比臺式機和筆記本更小的CPU頻率，無論何時評估你的網頁，你都必須使用CPU限制來模擬網頁在手機設備上表現。
在DevTools中，點擊Performance面板
確保Screenshots復選框選中
點擊Capture Settings（右上角的紅色設置圖標），展開其他設置
CPU中選擇4x slowdown，DevTools會將CPU頻率限制到平時的四分之一。
設置demo注意：如果測試其他頁面，如果想測試在低端機上的性能，可以選擇更低的倍數。這個只是為了更好的演示，選擇了小一點的限制。
連續點擊Add 10按鈕，知道明顯能看到藍色方框比之前慢了，在高端機上可能要點擊20次左右。
點擊Optimize按鈕，藍色方框應該移動地更快更平穩。
點擊Un-Optimize按鈕，藍色的方塊移動得更慢更松弛。
記錄運行性能注意：如果你沒有觀察到明顯變慢，嘗試點擊幾次Subtract 10按鈕再嘗試前面步驟。否則如果你添加了太多的藍色方框，就會耗盡CPU資源。
當你頁面運行網頁的優化版本，藍色方框移動速度會變快。為了更好的檢測出性能問題，我們記錄網頁非優化的版本。
點擊Record按鈕（見圖示），DevTools會在頁面運行時捕獲性能指標。
等待幾秒鐘
點擊Stop按鈕（見圖示），DevTools停止記錄，并開始處理數據，隨后將處理結果顯示在performance面板中,如下圖
分析結果關鍵的性能指標是FPS，其值如果是60FPS，用戶體驗會很好，使用網站的感受也是愉悅的。
FPS圖表查看FPS圖表（圖中藍色方框框住的部分），如果看到了紅色長條，就代表幀率太低并已經影響到用戶體驗了。一般情況下，綠色長條越高，FPS越高。
CPU圖表在FPS下面就是CPU圖表，圖表中的顏色和面板底部的Summarytab中的顏色是匹配的。CPU顏色越豐富，代表在錄制過程中CPU已經最大化了。如果這段豐富顏色的長條比較長，這就暗示網站應該想辦法讓CPU做更少的工作了，也就是說代碼邏輯需要做優化了。
順便提一下的就是，無論鼠標移動到FPS,CPU或者NET圖表上，DevTools都會顯示在該時間節點上的屏幕截圖，將你的鼠標左右移動，可以重放錄制畫面，這被稱為擦洗，對于手動分析動畫進程很有用。
Frames部分在Frames部分，如果將你的鼠標移動至綠色方塊部分，會顯示在該特定幀上的FPS值，此例中每幀可能遠低于60FPS的目標。的確，在這個例子中，這個頁面的性能很差并且能很明顯地被觀察到，但是在實際場景中，可能并不是那么的容易，所以，要用所有這些工具來進行綜合測量。
尋找瓶頸（追根溯源）現在你已經通過上面的各種方式了解并確信了這個網頁的性能不好，那么為什么會差呢？是什么導致它運行的這么差的呢？
Summary Tab當沒有選擇任何事件的時候，Summary tab顯示了網頁進程活動的分類。從圖中可以看出，這個網頁花費了太多的時間在渲染（rendering）上了。因此，你的目標就是減少渲染工作花費的時間。
Main部分展開Main部分，DevTools將顯示主線程上的隨著時間推移的活動火焰圖。x軸代表隨時間推移的記錄，每個長條代表一個事件，長條越寬，代表這個事件花費的時間越長。y軸代表調用堆棧，當你看到堆疊在一起的事件時，意味著上層事件發起了下層事件。
可以通過單擊、鼠標滾動或者拖動來選中FPS,CPU或NET圖標中的一部分，Main部分和Summary Tab就會只顯示選中部分的錄制信息。注意Animation Frame Fired事件右上角的紅色三角形圖標，該紅色三角圖標是這個事件有問題的警告。
單擊Animation Frame Fired事件,Summary tab會顯示該事件相關的信息。
注意reveal，點擊它，會高亮觸發Animation Frame Fired事件的事件。
注意app.js:95,點擊它，會跳轉到source面板對應的源碼及其對應的行號。
當選中了一個事件之后，可以使用鍵盤上的箭頭來選擇前面或者后面的事件
在Animation Frame Fired事件下面有一群紫色的事件。如果把它們放寬一點，會看到幾乎每個紫色事件的右上角都有紅色三角形圖標。點擊其中一個紫色事件（其實就是Layout事件），Summary tab會顯示該事件更詳細的信息。確實，這里有一個強制reflow的警告。
在Summary tab，點擊Recalculation Forced下面的app.js:71,DevTools會跳轉到觸發強制reflow的代碼行。
這個代碼的問題在于，在動畫的每一幀都改變了藍色方塊的樣式并計算了每個方塊在頁面的位置。因為樣式改變了，瀏覽器卻不確定是否是每一個方塊的位置都改變了，因此瀏覽器為了計算方塊的位置，只能對方塊重新布局。可以查看Avoid forced synchronous layouts這篇文來了解如何避免大型、復雜的布局和布局抖動。
更多的時間線事件參考，請點擊這里
利用chrome開發者工具執行加載性能評估打開你要評估的頁面
打開performance面板
點擊Start profiling and reload page（圖中藍色方框框住部分），DevTools在頁面重新加載時記錄性能指標，然后在加載完成后幾秒鐘自動停止錄制。
其他分析方式同上面的運行時性能評估。
總結如同評估運行時性能一樣設置了CPU限制，你也可以在設置里面設置network控制，來調整你想要的網絡速度環境。
可以使用chrome瀏覽器DevTools中的Performance面板來得到網頁的加載性能和運行時的性能數據，根據上文介紹的分析方法，結合RAIL模型來評估網頁性能的好與差。這是一個很有效的方法。具體如何提高網頁的性能呢？這又是一個大課題，相信網上也有不少與之相關的博文可以參考，筆者后續有時間也出相關博文。
參考文獻Get Started With Analyzing Runtime Performance
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/8792.html
摘要：特意對前端學習資源做一個匯總，方便自己學習查閱參考，和好友們共同進步。 特意對前端學習資源做一個匯總，方便自己學習查閱參考，和好友們共同進步。 本以為自己收藏的站點多，可以很快搞定，沒想到一入匯總深似海。還有很多不足&遺漏的地方，歡迎補充。有錯誤的地方，還請斧正... 托管: welcome to git，歡迎交流，感謝star 有好友反應和斧正，會及時更新，平時業務工作時也會不定期更...
摘要：就鹿晗宣布戀情導致微博宕機事件淺談大型網站高可用性架構中午吃飯刷著刷著微博發現微博突然掛了。用戶在使用瀏覽器訪問一個網站時需要先通過協議向服務器發送請求，之后服務器返回文件與響應信息。 webpack：從入門到真實項目配置 自從出現模塊化以后，大家可以將原本一坨代碼分離到個個模塊中，但是由此引發了一個問題。每個 JS 文件都需要從服務器去拿，由此會導致加載速度變慢。Webpack 最主...
摘要：層疊樣式表二修訂版這是對作出的官方說明。速查表兩份表來自一份關于基礎特性，一份關于布局。核心第一篇一份來自的基礎參考指南簡寫速查表簡寫形式參考書使用層疊樣式表基礎指南，包含使用的好處介紹個方法快速寫成高質量的寫出高效的一些提示。 迄今為止，我已經收集了100多個精通CSS的資源，它們能讓你更好地掌握CSS技巧，使你的布局設計脫穎而出。 CSS3 資源 20個學習CSS3的有用資源 C...
閱讀 997·2023-04-26 02:21
閱讀 2816·2021-09-24 09:47
閱讀 1606·2019-08-30 15:55
閱讀 2162·2019-08-30 14:01
閱讀 2319·2019-08-29 14:01
閱讀 2047·2019-08-29 12:46
閱讀 813·2019-08-26 13:27
閱讀 1932·2019-08-26 12:23
