性能優(yōu)化的指標(biāo)和工具

• 為什么要進(jìn)行前端性能優(yōu)化
• • 尋找性能瓶頸
  • 移動(dòng)端挑戰(zhàn)多
• 性能指標(biāo)和優(yōu)化目標(biāo)【了解行業(yè)標(biāo)準(zhǔn)】
• • 網(wǎng)絡(luò)加載性能
  • 交互體驗(yàn)
  • 總結(jié)
• RAIL測(cè)量模型【黃金指南】
• • 什么是RAIL
  • RAIL的目標(biāo)
  • RAIL評(píng)估標(biāo)準(zhǔn)
  • 性能測(cè)量工具
• 使用WebPageTest評(píng)估Web網(wǎng)站性能【快捷好用的在線分析工具】
• • 解讀WebPageTest的報(bào)告
  • WebPageTest
• 使用LightHouse分析性能【一站式全面呈現(xiàn)性能指標(biāo)】
• • 使用
  • • • Opportunities部分
    • Diagnostics
    • Passed audits
  • Lighthouse的安裝和使用
• 使用Chrome DevTools分析性能【最大法寶】
• • 使用Chrome DevTools進(jìn)行性能測(cè)試
• 常用的性能測(cè)量APIs
• • Web標(biāo)準(zhǔn)APIs

為什么要進(jìn)行前端性能優(yōu)化

互聯(lián)網(wǎng)發(fā)展得很快，我們現(xiàn)在做的內(nèi)容越來(lái)越多，功能越來(lái)越強(qiáng)大，頁(yè)面越做越漂亮，內(nèi)容多了速度會(huì)受到影響，用戶(hù)希望速度越來(lái)越快，這對(duì)于前端工程師挑戰(zhàn)越來(lái)越大，我們只有對(duì)我們的網(wǎng)站進(jìn)行持續(xù)的優(yōu)化，才能保證在發(fā)展過(guò)程中網(wǎng)站速度跟得上用戶(hù)體驗(yàn)的需求

現(xiàn)在的搜索引擎都會(huì)對(duì)網(wǎng)站性能進(jìn)行評(píng)估，高性能網(wǎng)站會(huì)出現(xiàn)在結(jié)果排名中更前的位置

尋找性能瓶頸

了解性能指標(biāo)-多快才算快

利用測(cè)量工具和APIs

優(yōu)化問(wèn)題，重新測(cè)量（迭代）

移動(dòng)端挑戰(zhàn)多

設(shè)備硬件，網(wǎng)速，屏幕尺寸，交互方式

移動(dòng)端用戶(hù)更缺少耐心，>3s加載導(dǎo)致53%的跳出率（bounce rate）

持續(xù)增長(zhǎng)的移動(dòng)用戶(hù)和移動(dòng)電商業(yè)務(wù)

性能指標(biāo)和優(yōu)化目標(biāo)【了解行業(yè)標(biāo)準(zhǔn)】

這邊結(jié)合淘寶網(wǎng)站的例子

網(wǎng)絡(luò)加載性能

打開(kāi)淘寶網(wǎng)站，點(diǎn)擊network>network setting,勾選如下三個(gè)復(fù)選框

進(jìn)行清空緩存并硬性重新加載

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

瀑布圖（網(wǎng)站的資源加載以瀑布的形式表達(dá)出來(lái)）如下

橫向看是具體的一個(gè)資源的加載，有色塊來(lái)表達(dá)加載的過(guò)程，色塊有不同的顏色，說(shuō)明一個(gè)資源的加載不是下載一個(gè)簡(jiǎn)單的單一過(guò)程，是經(jīng)歷了很多環(huán)節(jié)，懸浮在色塊上可以看到如下詳情列表

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

縱向看：
1.資源與資源之間的聯(lián)系：如果發(fā)生了堵塞，我們會(huì)發(fā)現(xiàn)資源是串行的，一個(gè)個(gè)按順序加載，如果是并行，就可以加快這個(gè)過(guò)程，這是我們優(yōu)化的一個(gè)點(diǎn)，期望有些資源可以進(jìn)行并行加載
2. 關(guān)鍵的時(shí)間節(jié)點(diǎn)：一根藍(lán)線一根紅線，藍(lán)色表示DOM加載完成時(shí)間，紅色表示頁(yè)面上所有資源加載完成的時(shí)間

network內(nèi)容比較多，一次分析不完或者后面想再進(jìn)行分析，可以把結(jié)果保存下來(lái)，可右鍵點(diǎn)擊空白處，Save all as HAR with content，保存所有的內(nèi)容為HAR，HAR是web的一個(gè)標(biāo)準(zhǔn)格式，主要是將我們性能測(cè)試的結(jié)果保存起來(lái)，以方便我們后續(xù)繼續(xù)使用，或者在其他性能分析工具中繼續(xù)分析，它是統(tǒng)一的標(biāo)準(zhǔn)

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

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

Speed Index 速度指數(shù)，速度指數(shù)標(biāo)準(zhǔn)是4s，如果你比4s小，你的網(wǎng)站是快的，如果比4s大，那是要進(jìn)行優(yōu)化的，這也要根據(jù)網(wǎng)站的性質(zhì)來(lái)看，比如google、百度搜索引擎的首頁(yè)，頁(yè)面上內(nèi)容比較少，性能測(cè)試出來(lái)會(huì)很好，但是淘寶首頁(yè)內(nèi)容比較多，電商網(wǎng)站想要在首頁(yè)展示更多的內(nèi)容，更多的商品，會(huì)用很多圖片，網(wǎng)頁(yè)速度會(huì)受到影響，所以不能一概追求指標(biāo)，指標(biāo)對(duì)我們來(lái)說(shuō)是指導(dǎo)性的作用，它是我們的一個(gè)目標(biāo)，我們只能不斷地去優(yōu)化，并不一定能夠真正達(dá)到它給我們指定的這個(gè)最優(yōu)的結(jié)果

交互體驗(yàn)

網(wǎng)站加載完成之后，用戶(hù)真正開(kāi)始使用網(wǎng)站，在這個(gè)過(guò)程中的交互體驗(yàn)，記住三點(diǎn)
1.交互響應(yīng)做到足夠快，比如點(diǎn)擊一級(jí)菜單是否能馬上列舉出二級(jí)菜單的內(nèi)容，搜索結(jié)果響應(yīng)快
2.畫(huà)面要足夠流暢，內(nèi)容往下滾動(dòng)畫(huà)面卡卡的，網(wǎng)頁(yè)動(dòng)畫(huà)卡卡的，這是因?yàn)樽龅膬?nèi)容沒(méi)有達(dá)到一定的幀數(shù)，比較流暢的幀數(shù)標(biāo)準(zhǔn)是60幀/s，如果低于這個(gè)標(biāo)準(zhǔn)就會(huì)覺(jué)得卡，f12里command+shift+p，輸入frame，選擇下圖紅框

會(huì)出現(xiàn)如下監(jiān)控，我們可以用它來(lái)看我們畫(huà)面上的幀數(shù)

3.所有的異步請(qǐng)求都能足夠快，多快算快，1s，希望所有的異步請(qǐng)求能在一秒之內(nèi)把數(shù)據(jù)返回回來(lái)，如果返回不回來(lái)怎么辦？可以做壓縮，如果壓縮完了還是返回不回來(lái)，就可以考慮前端交互上的一些優(yōu)化，比如加loading動(dòng)畫(huà)

總結(jié)

性能優(yōu)化-加載
1.理解加載瀑布圖
2.基于HAR存儲(chǔ)與重建性能信息
3.速度指數(shù)（Speed Index）
4.重要測(cè)量指標(biāo)：Speed Index，TTFB，頁(yè)面加載時(shí)間，首次渲染時(shí)間

性能優(yōu)化-響應(yīng)
1.交互動(dòng)作的反饋時(shí)間
2.幀率FPS
3.異步請(qǐng)求的完成時(shí)間

RAIL測(cè)量模型【黃金指南】

RAIL是google提出來(lái)的可以進(jìn)行量化測(cè)量的標(biāo)準(zhǔn)，通過(guò)這個(gè)模型可以指導(dǎo)我們性能優(yōu)化的一個(gè)目標(biāo)

什么是RAIL

Response 響應(yīng)，網(wǎng)站給用戶(hù)響應(yīng)的一個(gè)體驗(yàn)
Animation 動(dòng)畫(huà)，動(dòng)畫(huà)流暢度
Idle空閑，要讓瀏覽器有足夠的空閑時(shí)間，實(shí)際上這個(gè)第一點(diǎn)Response是相呼應(yīng)的，交互及時(shí)被響應(yīng)的前提是你要有足夠的空閑時(shí)間，當(dāng)瀏覽器進(jìn)行交互時(shí)，突然覺(jué)得特別卡，或者卡死動(dòng)不了，說(shuō)明瀏覽器主線程非常忙，已經(jīng)沒(méi)有時(shí)間處理你的響應(yīng)了，這時(shí)候就要考慮怎么加大Idle空閑時(shí)間，不能讓主線程始終處于繁忙狀態(tài)，這樣沒(méi)有足夠時(shí)間來(lái)處理用戶(hù)交互

如上圖可以看到主線程每時(shí)每刻都在做什么，它有沒(méi)有足夠的空閑，還可以打開(kāi)詳細(xì)，去查看它在做什么的時(shí)候具體做的一些事情
Load加載，資源網(wǎng)絡(luò)加載的時(shí)間

RAIL的目標(biāo)

讓良好的用戶(hù)體驗(yàn)成為性能優(yōu)化的目標(biāo)

RAIL評(píng)估標(biāo)準(zhǔn)

響應(yīng)：處理事件應(yīng)在50ms以?xún)?nèi)完成，50ms這個(gè)數(shù)是怎么得出來(lái)的？實(shí)際上google有非常廣的用戶(hù)基礎(chǔ)，會(huì)像這些用戶(hù)發(fā)起調(diào)查，對(duì)延時(shí)的體會(huì)和感受，把用戶(hù)反饋分成幾個(gè)組，形成不同的區(qū)間段，發(fā)現(xiàn)用戶(hù)能接受的最高延時(shí)是100ms，所以所有的用戶(hù)操作，我們必須在100ms內(nèi)反饋，這里說(shuō)的100ms是當(dāng)用戶(hù)進(jìn)入交互進(jìn)行輸入之后一直到給出反饋所經(jīng)歷的時(shí)間，但我們能真正做輸入處理的時(shí)間沒(méi)有100ms，瀏覽器還要對(duì)輸入進(jìn)行處理，這個(gè)要留個(gè)保守的時(shí)間，大概50ms

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

性能測(cè)量工具

Chrome DevTools開(kāi)發(fā)調(diào)試、性能評(píng)測(cè)
Lighthouse網(wǎng)站整體質(zhì)量評(píng)估，不光可以看網(wǎng)站性能，還能看seu，網(wǎng)站可訪問(wèn)性如何，是不是做了漸進(jìn)式的網(wǎng)絡(luò)應(yīng)用開(kāi)發(fā)等等，還能提出一些建議，告訴你怎么進(jìn)行相關(guān)的改進(jìn)
WebPageTest多測(cè)試站點(diǎn)、全面性能報(bào)告，可以在很多位置發(fā)起這個(gè)測(cè)試，來(lái)了解你在全球不同位置的用戶(hù)訪問(wèn)你的網(wǎng)站性能體驗(yàn)是怎么樣的

使用WebPageTest評(píng)估Web網(wǎng)站性能【快捷好用的在線分析工具】

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

上面是一個(gè)總結(jié)，下面是每一輪測(cè)試的具體詳情
First Byte 發(fā)出去的第一個(gè)請(qǐng)求，它得到響應(yīng)的時(shí)間是多久，反應(yīng)了后臺(tái)的處理能力和網(wǎng)絡(luò)回路的一個(gè)情況
Start Render首屏渲染，這是體驗(yàn)的第一步，我要看到內(nèi)容，而不是一直白屏
Speed Index 速度指數(shù)
Total Blocking Time 頁(yè)面被阻塞住了，用戶(hù)不能進(jìn)行交互，這個(gè)時(shí)間累積有多長(zhǎng)，綠色代表是達(dá)標(biāo)的
下圖是第一輪的詳情，從圖中可以看出First view的時(shí)間是4.892s

點(diǎn)擊瀑布圖可以查看詳細(xì)信息，拉到最后面有頁(yè)面可交互的時(shí)間（Page is Interactive），這是非常有用的信息，可以看出在整個(gè)加載過(guò)程中大部分頁(yè)面都是可以交互的，只有個(gè)別阻塞的時(shí)候

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

上圖圖片資源有并行同時(shí)進(jìn)行加載，極大的節(jié)約了時(shí)間，這塊消耗時(shí)間由最大的圖片加載時(shí)間決定

上圖黃色背景，后面標(biāo)了302，重定向，也就是我們這個(gè)資源不在原來(lái)你請(qǐng)求的位置了，需要進(jìn)行重定向才能找到真實(shí)的位置，這就提示我們這個(gè)地方可以做個(gè)優(yōu)化，可以直接去訪問(wèn)重定向的那個(gè)地址，這樣可以省出這個(gè)請(qǐng)求的時(shí)間

解讀WebPageTest的報(bào)告

waterfall chart請(qǐng)求瀑布圖
first view首次訪問(wèn)
repeat view二次訪問(wèn)

WebPageTest

在線進(jìn)行網(wǎng)站性能分析
如何本地部署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
制作一個(gè)自定義鏡像，方便日后再次進(jìn)行部署或者安裝
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分析性能【一站式全面呈現(xiàn)性能指標(biāo)】

LightHouse是google開(kāi)源的項(xiàng)目，之所以會(huì)使用很多的性能測(cè)量工具，是因?yàn)槊總€(gè)工具都有自身的特點(diǎn)，LightHouse除了會(huì)幫我們生成完整的性能測(cè)試報(bào)告之外，還會(huì)給我們提供很多有針對(duì)性?xún)?yōu)化的建議

使用

npm install lighthouse -g
lighthouse url
會(huì)出現(xiàn)如下頁(yè)面

當(dāng)看到如下地址內(nèi)容時(shí)，說(shuō)明測(cè)試報(bào)告已經(jīng)生成

把地址拷貝到瀏覽器里就可以看到測(cè)試報(bào)告內(nèi)容

Performance：性能
Accessibility：可訪問(wèn)性
Best Practices：最佳實(shí)踐
SEO：對(duì)搜索引擎有沒(méi)有做優(yōu)化
Progressive Web App（PWA）：google一直在推的概念，漸進(jìn)式應(yīng)用的加載，包括離線也能給客戶(hù)進(jìn)行訪問(wèn)的體驗(yàn)
這些是對(duì)網(wǎng)站整體質(zhì)量的評(píng)估
下面先看看網(wǎng)站的性能

First Contentful Paint：第一個(gè)有內(nèi)容的繪制時(shí)間，6.2秒有點(diǎn)長(zhǎng)，資源考慮壓縮

Speed Index 速度指數(shù)，頁(yè)面上所有可見(jiàn)內(nèi)容多久讓用戶(hù)看到，9.8s太長(zhǎng)

Largest Contentful Paint：所有可見(jiàn)資源里最大的那個(gè)花了多久看到

Time to Interative：什么時(shí)候用戶(hù)可以和你的網(wǎng)站進(jìn)行交互，這是很重要的用戶(hù)體驗(yàn)，上圖中有10個(gè)截屏，這10個(gè)截屏表現(xiàn)了用戶(hù)最開(kāi)始訪問(wèn)一直到整個(gè)頁(yè)面出來(lái)經(jīng)歷的過(guò)程，10張里有7張是白的，這說(shuō)明沒(méi)有做很好的漸進(jìn)式優(yōu)化，首屏不是逐步加載出來(lái)的，而是突然出來(lái)的，這體驗(yàn)很不好
下圖

Opportunities部分

會(huì)提供一些優(yōu)化建議，會(huì)告訴你應(yīng)該做什么，做了這項(xiàng)大概能提升多少

Remove unused Javascript，移除沒(méi)有用到的js，可以提升2.21s，有可能這些是后面使用的資源，可以考慮首屏先不加載，后面再加載
Eliminate render-blocking resources：減少渲染阻塞資源，要看下這個(gè)js是不是可以延遲加載，有沒(méi)有必要在第一時(shí)間加載，因?yàn)樗枞?#xff0c;后面沒(méi)辦法繼續(xù)，整體加載時(shí)間會(huì)因它延長(zhǎng)，下面測(cè)試看它是不是必須的
下圖中的log-reporter剛在評(píng)估報(bào)告中顯示會(huì)阻塞渲染資源，它在head部分，會(huì)第一時(shí)間加載和解析，勢(shì)必會(huì)阻塞后面資源的加載

如何確認(rèn)它是不是必須的，command+shift+p調(diào)出窗口，選擇第一個(gè)

增加log*.js都不讓加載的規(guī)則，再重新進(jìn)行加載，把名字為log的文件過(guò)濾出來(lái)，發(fā)現(xiàn)log*.js無(wú)法進(jìn)行加載

再去看看首屏內(nèi)容有沒(méi)有受到影響，沒(méi)有影響說(shuō)明不是必須的
調(diào)試工具里也有l(wèi)ighthouse，如下圖，可以勾選設(shè)備及測(cè)試項(xiàng)（如性能）

Diagnostics

診斷，這里面每一項(xiàng)也是很好的建議

Passed audits

會(huì)把測(cè)的網(wǎng)站沒(méi)有問(wèn)題的項(xiàng)列出來(lái)，也可以看看網(wǎng)站哪些地方做得比較好

Lighthouse的安裝和使用

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

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

分析自己的一個(gè)網(wǎng)站

一共發(fā)起了7個(gè)請(qǐng)求，請(qǐng)求到的資源總量是2.1兆，dom加載完成時(shí)間是1.9s，總的資源加載完成時(shí)間3.65s，這兩個(gè)時(shí)間都比較長(zhǎng)，因?yàn)槲覀兊木W(wǎng)站很簡(jiǎn)單

每個(gè)資源都有一些屬性：資源名稱(chēng) 大小 總的耗時(shí)，總的資源量高達(dá)2.1兆，可以點(diǎn)擊size大小排序，把資源從大到小進(jìn)行排序，從圖上可以看出第一個(gè)資源bundle.js高達(dá)1.4兆，因?yàn)槲覀兪褂脀ebpack進(jìn)行打包，所有js都打到這里面，相對(duì)較大些，可以做些優(yōu)化和精簡(jiǎn)，size里上下列出了兩個(gè)1.4兆，這兩個(gè)是不同的含義，上面的1.4兆是指這個(gè)資源通過(guò)網(wǎng)絡(luò)過(guò)來(lái)總的實(shí)際的大小，下面是指資源本身的大小，網(wǎng)絡(luò)傳輸?shù)拇笮『唾Y源的實(shí)際大小可能不相同，怎么才能不相同？在后臺(tái)把這個(gè)資源返回給前端之前可以對(duì)資源進(jìn)行壓縮，在網(wǎng)絡(luò)上經(jīng)過(guò)時(shí)這個(gè)資源的實(shí)際大小會(huì)變小，通過(guò)這樣的方式可以節(jié)約資源在網(wǎng)絡(luò)上的消耗

如上代碼對(duì)所有的請(qǐng)求資源進(jìn)行壓縮，然后再返回給前端

再次刷新看到，實(shí)際大小雖然是1.4兆，但在網(wǎng)絡(luò)傳輸時(shí)只有429kb，大大減少了通過(guò)網(wǎng)絡(luò)傳輸?shù)馁Y源大小，可以看到相應(yīng)的其他所有的資源在網(wǎng)絡(luò)傳輸時(shí)都被進(jìn)行了壓縮

dom加載時(shí)間過(guò)長(zhǎng)分析

點(diǎn)擊performance，可以點(diǎn)擊實(shí)習(xí)圓開(kāi)始記錄，在這個(gè)過(guò)程中頁(yè)面所發(fā)生的一切包括你的交互，都會(huì)被記錄下來(lái)，至到你點(diǎn)擊停止之后，這段過(guò)程中發(fā)生的一切都會(huì)出一個(gè)詳細(xì)的性能報(bào)告；還有一種方式是點(diǎn)擊刷新按鈕，就會(huì)刷新我們的頁(yè)面，記錄頁(yè)面從開(kāi)始刷新一直到整個(gè)所有資源加載完成這個(gè)過(guò)程所發(fā)生的一切，然后進(jìn)行性能分析，這就是我們關(guān)心的網(wǎng)絡(luò)加載性能，我們點(diǎn)擊刷新按鈕，經(jīng)過(guò)一段時(shí)間就得到我們的性能分析報(bào)告

找到Main主線程，可以看到隨著時(shí)間推移，我們的主線程都做了哪些任務(wù)，可以通過(guò)滾輪進(jìn)行放大縮小，點(diǎn)擊住拖動(dòng)畫(huà)面進(jìn)行移動(dòng)，我們看下這個(gè)主線程都做了哪些任務(wù)，它是自上而下類(lèi)似堆棧的結(jié)構(gòu)列舉的，也就是把我們整個(gè)調(diào)用關(guān)系都很清晰的表示出來(lái)，比如說(shuō)我們做了個(gè)Task，Task做了什么事呢，首先分析了腳本，腳本里會(huì)有一些相關(guān)的調(diào)用，一層一層會(huì)把我們的調(diào)用關(guān)系全部都列出來(lái)，一直到最后，這非常清晰，有助于我們做具體的一個(gè)分析

這邊還有個(gè)Timings，關(guān)鍵的時(shí)間節(jié)點(diǎn)，DCL就是dom加載完成時(shí)間，它什么時(shí)候發(fā)生的，發(fā)生之前都做了什么，從圖中可以看出主線程的任務(wù)恰巧是發(fā)生在這之前的，這個(gè)執(zhí)行時(shí)間很長(zhǎng)，很有可能是這個(gè)導(dǎo)致DCL來(lái)得過(guò)于晚，所以了解下主線程到底做了什么

可以將主線程拉到最后面，看看最終調(diào)用是什么，因?yàn)橥詈笳{(diào)用用到的是我們自己的代碼，前面很多可能都是框架本身的一些內(nèi)容，可以看到最后一直在忙碌的做calculatePi這個(gè)函數(shù)，這是我們故意在代碼里埋下的長(zhǎng)任務(wù)
打開(kāi)代碼看下

看到這個(gè)組件在構(gòu)建的時(shí)候調(diào)用了calculatePi函數(shù)，制造了1.5s的延遲，這個(gè)函數(shù)就導(dǎo)致了加載的過(guò)程被堵塞，有1.5s的延遲
通過(guò)performance這個(gè)工具，可以很好的定位出導(dǎo)致這些產(chǎn)生長(zhǎng)任務(wù)甚至堵塞的一些任務(wù)的發(fā)生原因及具體的函數(shù)位置

Disable cache，開(kāi)發(fā)過(guò)程中要修改很多代碼，如果有緩存，修改的代碼不能立即生效，看到的還是緩存效果，所以通常開(kāi)發(fā)時(shí)會(huì)把這個(gè)勾選上；但當(dāng)我們進(jìn)行性能評(píng)測(cè)時(shí)，要把這個(gè)勾選去掉，因?yàn)槲覀兏P(guān)心用戶(hù)在第二次第三次訪問(wèn)時(shí)設(shè)置的緩存有沒(méi)有生效，因?yàn)檫@些緩存會(huì)提高再次訪問(wèn)的速度

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

常用的功能點(diǎn)擊esc會(huì)列舉出來(lái)，相當(dāng)于另外一個(gè)功能菜單，把我們之前經(jīng)常用的功能都列在這，例如Request blocking讓一些資源不能進(jìn)行加載，之后對(duì)我們網(wǎng)站有什么影響，會(huì)不會(huì)導(dǎo)致性能提升還是網(wǎng)站功能異常了

Rendering渲染也是我們關(guān)心的一塊，比如FPS刷新頻率，Paint flashing當(dāng)我們頁(yè)面滾動(dòng)時(shí)可以標(biāo)記出哪些地方發(fā)生重繪，因?yàn)橹乩L制是對(duì)性能影響比較大的一塊內(nèi)容，要避免重繪事件的發(fā)生，提高網(wǎng)站性能

Performance monitor：性能監(jiān)測(cè)，可以看到cpu使用情況，js堆占用情況，當(dāng)前頁(yè)面dom節(jié)點(diǎn)數(shù)，dom節(jié)點(diǎn)數(shù)也是影響比較大的，dom節(jié)點(diǎn)數(shù)越多，層級(jí)越深，對(duì)性能影響越大，還有布局、樣式的重新計(jì)算，這些都可以通過(guò)monitor進(jìn)行監(jiān)測(cè)

使用Chrome DevTools進(jìn)行性能測(cè)試

Audit(Lighthouse)
Throttling調(diào)整網(wǎng)絡(luò)吞吐
Performance性能分析
Network網(wǎng)絡(luò)加載分析

常用的性能測(cè)量APIs

經(jīng)常需要真正實(shí)時(shí)獲取用戶(hù)在真實(shí)使用過(guò)程中性能的數(shù)據(jù)，這時(shí)候就需要用web提供的標(biāo)準(zhǔn)api進(jìn)行動(dòng)態(tài)測(cè)量

Web標(biāo)準(zhǔn)APIs

關(guān)鍵時(shí)間節(jié)點(diǎn)（Navigation Timing，Resource Timing）
網(wǎng)絡(luò)狀態(tài)（Network APIs）
客戶(hù)端服務(wù)端協(xié)商（HTTP Client Hints）& 網(wǎng)絡(luò)顯示狀態(tài)（UI APIs）
之前的性能測(cè)量工具都有一些關(guān)鍵的時(shí)間節(jié)點(diǎn)，比如TTFB、首屏等，這些時(shí)間節(jié)點(diǎn)是通過(guò)瀏覽器按照標(biāo)準(zhǔn)實(shí)現(xiàn)的特定的api獲取的

拿到這個(gè)數(shù)據(jù)后可以發(fā)送給后臺(tái)，這樣就可以上報(bào)實(shí)時(shí)的性能數(shù)據(jù)信息

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

通過(guò)api發(fā)現(xiàn)長(zhǎng)任務(wù)，這樣可以實(shí)時(shí)監(jiān)測(cè)和上報(bào)


你做的是視頻網(wǎng)站，如果用戶(hù)不再看你這個(gè)頁(yè)面了，這時(shí)候需要考慮節(jié)流，不再進(jìn)行視頻內(nèi)容的加載

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

然后在頁(yè)面上切換tab進(jìn)行測(cè)試

判斷當(dāng)前的網(wǎng)絡(luò)狀態(tài)進(jìn)行有針對(duì)性資源的加載，網(wǎng)絡(luò)狀態(tài)不好時(shí)使用稍微模糊的圖片

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。