性能優化的指標和工具

• 為什么要進行前端性能優化
• • 尋找性能瓶頸
  • 移動端挑戰多
• 性能指標和優化目標【了解行業標準】
• • 網絡加載性能
  • 交互體驗
  • 總結
• RAIL測量模型【黃金指南】
• • 什么是RAIL
  • RAIL的目標
  • RAIL評估標準
  • 性能測量工具
• 使用WebPageTest評估Web網站性能【快捷好用的在線分析工具】
• • 解讀WebPageTest的報告
  • WebPageTest
• 使用LightHouse分析性能【一站式全面呈現性能指標】
• • 使用
  • • • Opportunities部分
    • Diagnostics
    • Passed audits
  • Lighthouse的安裝和使用
• 使用Chrome DevTools分析性能【最大法寶】
• • 使用Chrome DevTools進行性能測試
• 常用的性能測量APIs
• • Web標準APIs

為什么要進行前端性能優化

互聯網發展得很快，我們現在做的內容越來越多，功能越來越強大，頁面越做越漂亮，內容多了速度會受到影響，用戶希望速度越來越快，這對于前端工程師挑戰越來越大，我們只有對我們的網站進行持續的優化，才能保證在發展過程中網站速度跟得上用戶體驗的需求

現在的搜索引擎都會對網站性能進行評估，高性能網站會出現在結果排名中更前的位置

尋找性能瓶頸

了解性能指標-多快才算快

利用測量工具和APIs

優化問題，重新測量（迭代）

移動端挑戰多

設備硬件，網速，屏幕尺寸，交互方式

移動端用戶更缺少耐心，>3s加載導致53%的跳出率（bounce rate）

持續增長的移動用戶和移動電商業務

性能指標和優化目標【了解行業標準】

這邊結合淘寶網站的例子

網絡加載性能

打開淘寶網站，點擊network>network setting,勾選如下三個復選框

進行清空緩存并硬性重新加載

上圖紅色框選的為概要信息
0 / 63 requests 共63個請求
0 B / 1.2 MB transferred
0 B / 1.9 MB resources 總資源量1.9M
Finish: 2.1 min
DOMContentLoaded: 573 ms DOM完成的加載時間
Load: 770 ms 總資源的加載時間

瀑布圖（網站的資源加載以瀑布的形式表達出來）如下

橫向看是具體的一個資源的加載，有色塊來表達加載的過程，色塊有不同的顏色，說明一個資源的加載不是下載一個簡單的單一過程，是經歷了很多環節，懸浮在色塊上可以看到如下詳情列表

Queueing 資源需要經過排隊才能從瀏覽器發出去，瀏覽器會對資源請求進行優先級安排，高優先級的內容先安排進行請求
DNS Lookup 每個資源實際上有個域名，域名最終要被翻譯成ip，然后找到這個服務器，所有有這個DNS查找的過程
Initial connection找到資源之后，客戶端與服務器要建立鏈接，這是我們TCP鏈接建立的過程
SSL 有的網站是https的，為了保證安全性，使用了SSL證書，SSL的工作原理是什么，最上來開始要進行安全性驗證，管這個過程叫SSL協商，這個過程也會耗時
Request sent 請求發送出去
Waiting(TTFB) 發送出去請求到資源真正回來中間的等待時間，請求發出到請求回來經歷多久的時間，這個參數很重要，能給用戶最直觀感受網站快慢的參數，如果TTFB高的話，相當于請求發出去了，資源一直沒回來，瀏覽器這邊就是白屏，如果很快的話，資源回來之后就可以快速進行解析和渲染及后面的一些步驟，它有兩個重要的影響因素：一個是后臺的處理能力，服務器響應有多快，這個請求到了后臺之后，后臺可能還要去查數據庫，可能還要對數據進行組織和處理，才把數據返回，最主要的是表達了后臺的處理能力，其次是你的資源，這條回路網絡的一個情況，我發出去請求，然后回來到底會不會有延時
Content Download下載，如果下載的藍條越長，說明這個資源越大，過長肯定不好，因為資源下載時間越長，等待的時間就越長，尤其有些資源還會造成堵塞，就是如果它本身一致在下載，它后面的資源都無法加載，只能等它完了之后才能再繼續，這樣會對我們瀏覽器的加載過程整體的時間造成延誤

縱向看：
1.資源與資源之間的聯系：如果發生了堵塞，我們會發現資源是串行的，一個個按順序加載，如果是并行，就可以加快這個過程，這是我們優化的一個點，期望有些資源可以進行并行加載
2. 關鍵的時間節點：一根藍線一根紅線，藍色表示DOM加載完成時間，紅色表示頁面上所有資源加載完成的時間

network內容比較多，一次分析不完或者后面想再進行分析，可以把結果保存下來，可右鍵點擊空白處，Save all as HAR with content，保存所有的內容為HAR，HAR是web的一個標準格式，主要是將我們性能測試的結果保存起來，以方便我們后續繼續使用，或者在其他性能分析工具中繼續分析，它是統一的標準

Lighthouse是google給我們集成到chrome里的一個性能測量工具

如上圖報告，可以看出
滿分100分，這次測試得分82，我們每次測試時網絡情況是會變化的，所以你的測試結果不能每次保證一樣，所以使用測試工具時，建議多測幾次，取一個平均的情況
First Contentful Paint：第一個有內容的繪制出現的時間，內容也包括文字或者圖片，主要不再白屏，出現了內容，我們認為這個時間就是我們記錄的時間，從白屏到真正出現內容一共2.6s，黃色表示warning，稍微有問題，可以進行改進；紅色表示問題比較大的，需要嚴重優化的東西；綠色是做得非常好

Speed Index 速度指數，速度指數標準是4s，如果你比4s小，你的網站是快的，如果比4s大，那是要進行優化的，這也要根據網站的性質來看，比如google、百度搜索引擎的首頁，頁面上內容比較少，性能測試出來會很好，但是淘寶首頁內容比較多，電商網站想要在首頁展示更多的內容，更多的商品，會用很多圖片，網頁速度會受到影響，所以不能一概追求指標，指標對我們來說是指導性的作用，它是我們的一個目標，我們只能不斷地去優化，并不一定能夠真正達到它給我們指定的這個最優的結果

交互體驗

網站加載完成之后，用戶真正開始使用網站，在這個過程中的交互體驗，記住三點
1.交互響應做到足夠快，比如點擊一級菜單是否能馬上列舉出二級菜單的內容，搜索結果響應快
2.畫面要足夠流暢，內容往下滾動畫面卡卡的，網頁動畫卡卡的，這是因為做的內容沒有達到一定的幀數，比較流暢的幀數標準是60幀/s，如果低于這個標準就會覺得卡，f12里command+shift+p，輸入frame，選擇下圖紅框

會出現如下監控，我們可以用它來看我們畫面上的幀數

3.所有的異步請求都能足夠快，多快算快，1s，希望所有的異步請求能在一秒之內把數據返回回來，如果返回不回來怎么辦？可以做壓縮，如果壓縮完了還是返回不回來，就可以考慮前端交互上的一些優化，比如加loading動畫

總結

性能優化-加載
1.理解加載瀑布圖
2.基于HAR存儲與重建性能信息
3.速度指數（Speed Index）
4.重要測量指標：Speed Index，TTFB，頁面加載時間，首次渲染時間

性能優化-響應
1.交互動作的反饋時間
2.幀率FPS
3.異步請求的完成時間

RAIL測量模型【黃金指南】

RAIL是google提出來的可以進行量化測量的標準，通過這個模型可以指導我們性能優化的一個目標

什么是RAIL

Response 響應，網站給用戶響應的一個體驗
Animation 動畫，動畫流暢度
Idle空閑，要讓瀏覽器有足夠的空閑時間，實際上這個第一點Response是相呼應的，交互及時被響應的前提是你要有足夠的空閑時間，當瀏覽器進行交互時，突然覺得特別卡，或者卡死動不了，說明瀏覽器主線程非常忙，已經沒有時間處理你的響應了，這時候就要考慮怎么加大Idle空閑時間，不能讓主線程始終處于繁忙狀態，這樣沒有足夠時間來處理用戶交互

如上圖可以看到主線程每時每刻都在做什么，它有沒有足夠的空閑，還可以打開詳細，去查看它在做什么的時候具體做的一些事情
Load加載，資源網絡加載的時間

RAIL的目標

讓良好的用戶體驗成為性能優化的目標

RAIL評估標準

響應：處理事件應在50ms以內完成，50ms這個數是怎么得出來的？實際上google有非常廣的用戶基礎，會像這些用戶發起調查，對延時的體會和感受，把用戶反饋分成幾個組，形成不同的區間段，發現用戶能接受的最高延時是100ms，所以所有的用戶操作，我們必須在100ms內反饋，這里說的100ms是當用戶進入交互進行輸入之后一直到給出反饋所經歷的時間，但我們能真正做輸入處理的時間沒有100ms，瀏覽器還要對輸入進行處理，這個要留個保守的時間，大概50ms

動畫：每10ms產生一幀，60幀/s換算后一幀是1/60，大概是16ms，中間差了6ms，瀏覽器去獲取這一幀，實際上也要些時間，大概6ms左右，這個也要考慮進去，所以我們產生一幀要保證在10ms之內
空閑：盡可能增加空閑時間，與響應是相呼應的，只有空閑足夠多，當響應來的時候，我們才有足夠的時間去進行處理，不能讓我們的處理時間太長，多長是長，50ms，如果前置時間50ms，處理時間50ms，那用戶的交互欄根本沒時間去處理，用戶點擊后就會感覺卡住了，后面要用到的內容利用空閑時間慢慢加載可以，一些業務邏輯計算放在前端做是不合理的，大量業務相關運算相關的內容，應放在后臺做
加載：在5s內完成內容加載并可以交互，其實這5s是非常高的要求，分兩個層面開看，第一個層面，要完成內容的加載，這5s不光是加載這么簡單，加載完了還要解析，解析完了還要進行渲染，所有這些時間都要算在內，這樣才能達到用戶可以進行交互的目的；第二個層面我們要看的是，使用的移動設備，網絡環境有可能非常差

性能測量工具

Chrome DevTools開發調試、性能評測
Lighthouse網站整體質量評估，不光可以看網站性能，還能看seu，網站可訪問性如何，是不是做了漸進式的網絡應用開發等等，還能提出一些建議，告訴你怎么進行相關的改進
WebPageTest多測試站點、全面性能報告，可以在很多位置發起這個測試，來了解你在全球不同位置的用戶訪問你的網站性能體驗是怎么樣的

使用WebPageTest評估Web網站性能【快捷好用的在線分析工具】

訪問https://webpagetest.org/，輸入測試網站地址
Test Location選擇測試地點
Browser選擇瀏覽器
Connection配置網絡連接的情況
Number of Tests to Run表示測試輪數
Repeat View結果視圖，通常選擇First View and Repeat View，用戶首次訪問頁面和第二次訪問，可以對靜態資源做緩存，第二次訪問肯定比第一次快，所以通過這兩個視圖的對比，可以看出緩存的工作做得好不好；Capture Video，捕捉視頻，如果你選的是Chrome，這個可以勾選上，測試完成后會給你錄一個截屏，是一段視頻，你可以非常直觀的通過這段視頻了解到你的用戶在這指定的設備上訪問的一個體驗
開始測試后，結果如下

上面是一個總結，下面是每一輪測試的具體詳情
First Byte 發出去的第一個請求，它得到響應的時間是多久，反應了后臺的處理能力和網絡回路的一個情況
Start Render首屏渲染，這是體驗的第一步，我要看到內容，而不是一直白屏
Speed Index 速度指數
Total Blocking Time 頁面被阻塞住了，用戶不能進行交互，這個時間累積有多長，綠色代表是達標的
下圖是第一輪的詳情，從圖中可以看出First view的時間是4.892s

點擊瀑布圖可以查看詳細信息，拉到最后面有頁面可交互的時間（Page is Interactive），這是非常有用的信息，可以看出在整個加載過程中大部分頁面都是可以交互的，只有個別阻塞的時候

Browser Main Thread主線程占用情況，什么時候比較忙，整體還可以，大部分空閑還是比較多的
CPU Utilization 帶寬、CPU的占用使用情況

上圖圖片資源有并行同時進行加載，極大的節約了時間，這塊消耗時間由最大的圖片加載時間決定

上圖黃色背景，后面標了302，重定向，也就是我們這個資源不在原來你請求的位置了，需要進行重定向才能找到真實的位置，這就提示我們這個地方可以做個優化，可以直接去訪問重定向的那個地址，這樣可以省出這個請求的時間

解讀WebPageTest的報告

waterfall chart請求瀑布圖
first view首次訪問
repeat view二次訪問

WebPageTest

在線進行網站性能分析
如何本地部署WebPageTest工具
安裝docker
docker pull webpagetest/server
docker pull webpagetest/agent
docker run -d -p 4000:80 webpagetest/server
docker run -d -p 4001:80 --network=“host” -e “SERVER_URL=http://localhost:4000/work/” -e “LOCATION=Test” webpagetest/agent
制作一個自定義鏡像，方便日后再次進行部署或者安裝
mkdir wpt-mac-server
cd wpt-mac-server
vim Dockerfile

vim locations.ini

docker build -t wpt-mac-server .
cd …/
mkdir wpt-mac-agent
cd wpt-mac-agent
vim Dockerfile

vim script.sh

chmod u+x script.sh
docker build -t wpt-mac-agent .

使用LightHouse分析性能【一站式全面呈現性能指標】

LightHouse是google開源的項目，之所以會使用很多的性能測量工具，是因為每個工具都有自身的特點，LightHouse除了會幫我們生成完整的性能測試報告之外，還會給我們提供很多有針對性優化的建議

使用

npm install lighthouse -g
lighthouse url
會出現如下頁面

當看到如下地址內容時，說明測試報告已經生成

把地址拷貝到瀏覽器里就可以看到測試報告內容

Performance：性能
Accessibility：可訪問性
Best Practices：最佳實踐
SEO：對搜索引擎有沒有做優化
Progressive Web App（PWA）：google一直在推的概念，漸進式應用的加載，包括離線也能給客戶進行訪問的體驗
這些是對網站整體質量的評估
下面先看看網站的性能

First Contentful Paint：第一個有內容的繪制時間，6.2秒有點長，資源考慮壓縮

Speed Index 速度指數，頁面上所有可見內容多久讓用戶看到，9.8s太長

Largest Contentful Paint：所有可見資源里最大的那個花了多久看到

Time to Interative：什么時候用戶可以和你的網站進行交互，這是很重要的用戶體驗，上圖中有10個截屏，這10個截屏表現了用戶最開始訪問一直到整個頁面出來經歷的過程，10張里有7張是白的，這說明沒有做很好的漸進式優化，首屏不是逐步加載出來的，而是突然出來的，這體驗很不好
下圖

Opportunities部分

會提供一些優化建議，會告訴你應該做什么，做了這項大概能提升多少

Remove unused Javascript，移除沒有用到的js，可以提升2.21s，有可能這些是后面使用的資源，可以考慮首屏先不加載，后面再加載
Eliminate render-blocking resources：減少渲染阻塞資源，要看下這個js是不是可以延遲加載，有沒有必要在第一時間加載，因為它阻塞了，后面沒辦法繼續，整體加載時間會因它延長，下面測試看它是不是必須的
下圖中的log-reporter剛在評估報告中顯示會阻塞渲染資源，它在head部分，會第一時間加載和解析，勢必會阻塞后面資源的加載

如何確認它是不是必須的，command+shift+p調出窗口，選擇第一個

增加log*.js都不讓加載的規則，再重新進行加載，把名字為log的文件過濾出來，發現log*.js無法進行加載

再去看看首屏內容有沒有受到影響，沒有影響說明不是必須的
調試工具里也有lighthouse，如下圖，可以勾選設備及測試項（如性能）

Diagnostics

診斷，這里面每一項也是很好的建議

Passed audits

會把測的網站沒有問題的項列出來，也可以看看網站哪些地方做得比較好

Lighthouse的安裝和使用

本地npm安裝Lighthouse
chrome Devtools中使用
通過chrome web store安裝插件

使用Chrome DevTools分析性能【最大法寶】

分析自己的一個網站

一共發起了7個請求，請求到的資源總量是2.1兆，dom加載完成時間是1.9s，總的資源加載完成時間3.65s，這兩個時間都比較長，因為我們的網站很簡單

每個資源都有一些屬性：資源名稱 大小 總的耗時，總的資源量高達2.1兆，可以點擊size大小排序，把資源從大到小進行排序，從圖上可以看出第一個資源bundle.js高達1.4兆，因為我們使用webpack進行打包，所有js都打到這里面，相對較大些，可以做些優化和精簡，size里上下列出了兩個1.4兆，這兩個是不同的含義，上面的1.4兆是指這個資源通過網絡過來總的實際的大小，下面是指資源本身的大小，網絡傳輸的大小和資源的實際大小可能不相同，怎么才能不相同？在后臺把這個資源返回給前端之前可以對資源進行壓縮，在網絡上經過時這個資源的實際大小會變小，通過這樣的方式可以節約資源在網絡上的消耗

如上代碼對所有的請求資源進行壓縮，然后再返回給前端

再次刷新看到，實際大小雖然是1.4兆，但在網絡傳輸時只有429kb，大大減少了通過網絡傳輸的資源大小，可以看到相應的其他所有的資源在網絡傳輸時都被進行了壓縮

dom加載時間過長分析

點擊performance，可以點擊實習圓開始記錄，在這個過程中頁面所發生的一切包括你的交互，都會被記錄下來，至到你點擊停止之后，這段過程中發生的一切都會出一個詳細的性能報告；還有一種方式是點擊刷新按鈕，就會刷新我們的頁面，記錄頁面從開始刷新一直到整個所有資源加載完成這個過程所發生的一切，然后進行性能分析，這就是我們關心的網絡加載性能，我們點擊刷新按鈕，經過一段時間就得到我們的性能分析報告

找到Main主線程，可以看到隨著時間推移，我們的主線程都做了哪些任務，可以通過滾輪進行放大縮小，點擊住拖動畫面進行移動，我們看下這個主線程都做了哪些任務，它是自上而下類似堆棧的結構列舉的，也就是把我們整個調用關系都很清晰的表示出來，比如說我們做了個Task，Task做了什么事呢，首先分析了腳本，腳本里會有一些相關的調用，一層一層會把我們的調用關系全部都列出來，一直到最后，這非常清晰，有助于我們做具體的一個分析

這邊還有個Timings，關鍵的時間節點，DCL就是dom加載完成時間，它什么時候發生的，發生之前都做了什么，從圖中可以看出主線程的任務恰巧是發生在這之前的，這個執行時間很長，很有可能是這個導致DCL來得過于晚，所以了解下主線程到底做了什么

可以將主線程拉到最后面，看看最終調用是什么，因為往往最后調用用到的是我們自己的代碼，前面很多可能都是框架本身的一些內容，可以看到最后一直在忙碌的做calculatePi這個函數，這是我們故意在代碼里埋下的長任務
打開代碼看下

看到這個組件在構建的時候調用了calculatePi函數，制造了1.5s的延遲，這個函數就導致了加載的過程被堵塞，有1.5s的延遲
通過performance這個工具，可以很好的定位出導致這些產生長任務甚至堵塞的一些任務的發生原因及具體的函數位置

Disable cache，開發過程中要修改很多代碼，如果有緩存，修改的代碼不能立即生效，看到的還是緩存效果，所以通常開發時會把這個勾選上；但當我們進行性能評測時，要把這個勾選去掉，因為我們更關心用戶在第二次第三次訪問時設置的緩存有沒有生效，因為這些緩存會提高再次訪問的速度

網絡吞吐：可以調整我們現在網絡的狀態，模擬用戶網絡情況，比較快的3g，比較慢的3g，離線，也可以自定義添加網絡吞吐情況，比如添加自定義4g，4g大概下載速度在5-12兆，所以設置Download為5120，上行速度一般是2-5兆，所以設置Upload為下限2048，Latency延遲，考慮到用戶所在位置信號不是很好，延遲比較高，設置800ms

常用的功能點擊esc會列舉出來，相當于另外一個功能菜單，把我們之前經常用的功能都列在這，例如Request blocking讓一些資源不能進行加載，之后對我們網站有什么影響，會不會導致性能提升還是網站功能異常了

Rendering渲染也是我們關心的一塊，比如FPS刷新頻率，Paint flashing當我們頁面滾動時可以標記出哪些地方發生重繪，因為重繪制是對性能影響比較大的一塊內容，要避免重繪事件的發生，提高網站性能

Performance monitor：性能監測，可以看到cpu使用情況，js堆占用情況，當前頁面dom節點數，dom節點數也是影響比較大的，dom節點數越多，層級越深，對性能影響越大，還有布局、樣式的重新計算，這些都可以通過monitor進行監測

使用Chrome DevTools進行性能測試

Audit(Lighthouse)
Throttling調整網絡吞吐
Performance性能分析
Network網絡加載分析

常用的性能測量APIs

經常需要真正實時獲取用戶在真實使用過程中性能的數據，這時候就需要用web提供的標準api進行動態測量

Web標準APIs

關鍵時間節點（Navigation Timing，Resource Timing）
網絡狀態（Network APIs）
客戶端服務端協商（HTTP Client Hints）& 網絡顯示狀態（UI APIs）
之前的性能測量工具都有一些關鍵的時間節點，比如TTFB、首屏等，這些時間節點是通過瀏覽器按照標準實現的特定的api獲取的

拿到這個數據后可以發送給后臺，這樣就可以上報實時的性能數據信息

DNS 解析耗時: domainLookupEnd - domainLookupStart TCP 連接耗時: connectEnd - connectStart SSL 安全連接耗時: connectEnd - secureConnectionStart 網絡請求耗時 (TTFB): responseStart - requestStart 數據傳輸耗時: responseEnd - responseStart DOM 解析耗時: domInteractive - responseEnd 資源加載耗時: loadEventStart - domContentLoadedEventEnd First Byte時間: responseStart - domainLookupStart 白屏時間: responseEnd - fetchStart 首次可交互時間: domInteractive - fetchStart DOM Ready 時間: domContentLoadEventEnd - fetchStart 頁面完全加載時間: loadEventStart - fetchStart http 頭部大小： transferSize - encodedBodySize 重定向次數：performance.navigation.redirectCount 重定向耗時: redirectEnd - redirectStart

通過api發現長任務，這樣可以實時監測和上報


你做的是視頻網站，如果用戶不再看你這個頁面了，這時候需要考慮節流，不再進行視頻內容的加載

let vEvent = 'visibilitychange' if(document.webkitHidden != undefined) {// webkit事件名稱vEvent = 'webkitvisibilitychange' } function visibilityChanged () {// 頁面不可見if (document.hidden || document.webkitHidden) {console.log('Web page is hidden')} else {// 頁面可見console.log('Web page is visible')} } document.addEventListener(vEvent, visibilityChanged, false);

然后在頁面上切換tab進行測試

判斷當前的網絡狀態進行有針對性資源的加載，網絡狀態不好時使用稍微模糊的圖片

總結

以上是生活随笔為你收集整理的（二）性能优化的指标和工具 (告别前端小白，成为大神的必经之路)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。