五、前端性能檢測實(shí)踐

1、常用的檢測工具

Lighthouse、Chrome開發(fā)者工具中與性能檢測相關(guān)的一些工具面板、頁面加載性能分析工具PageSpeed Insights、專業(yè)的性能檢測工具WEBPAGETEST等

1、Chrome 任務(wù)管理器

通過Chrome任務(wù)管理器我們可以查看當(dāng)前Chrome瀏覽器中，所有進(jìn)程關(guān)于GPU、網(wǎng)絡(luò)和內(nèi)存空間的使用情況，這些進(jìn)程包括當(dāng)前打開的各個(gè)頁簽，安裝的各種擴(kuò)展插件，以及GPU、網(wǎng)絡(luò)、渲染等瀏覽器的默認(rèn)進(jìn)程，通過監(jiān)控這些數(shù)據(jù)，我們可以在有異于其他進(jìn)程的大幅開銷出現(xiàn)時(shí)，去定位到可能存在內(nèi)存泄漏或網(wǎng)絡(luò)資源加載異常的問題進(jìn)程。

Chrome 任務(wù)管理器

2、Network 面板

Network面板是Chrome開發(fā)者工具中一個(gè)經(jīng)常會被用到的工具面板，通過它可以查看到網(wǎng)站所有資源的請求情況，包括加載時(shí)間、尺寸大小、優(yōu)先級設(shè)置及HTTP緩存觸發(fā)情況等信息，從而幫助我們發(fā)現(xiàn)可能由于未進(jìn)行有效壓縮而導(dǎo)致資源尺寸過大的問題，或者未合理配置緩存策略導(dǎo)致二次請求加載時(shí)間過長的問題等。

3、Coverage 面板

可以通過它監(jiān)控并統(tǒng)計(jì)出網(wǎng)站應(yīng)用運(yùn)行過程中代碼執(zhí)行的覆蓋率情況。該面板統(tǒng)計(jì)的對象是JavaScript腳本文件與CSS樣式表文件，統(tǒng)計(jì)結(jié)果主要包括：每個(gè)文件的字節(jié)大小、執(zhí)行過程中已覆蓋的代碼字節(jié)數(shù)，以及可視化的覆蓋率條形圖。

根據(jù)執(zhí)行結(jié)果我們能夠發(fā)現(xiàn)，在啟動錄制的過程中到底有哪些尺寸較大的代碼文件執(zhí)行覆蓋率較低，這就意味著有些代碼文件中可能存在較多的無用代碼，更準(zhǔn)確地說是暫時(shí)沒用到的代碼。

開發(fā)者可以據(jù)此將執(zhí)行覆蓋率較低的代碼文件進(jìn)行拆分，將首屏渲染階段暫時(shí)不會執(zhí)行到的代碼部分單獨(dú)打包，僅在需要的時(shí)候再去加載。

同時(shí)對規(guī)模較大且迭代周期較長的項(xiàng)目來說，工程代碼中會包含一些永遠(yuǎn)都不會執(zhí)行到的代碼，而使用Webpack的Tree Shaking僅能根據(jù)export進(jìn)行無關(guān)聯(lián)引用，那么此時(shí)Coverage面板就為優(yōu)化提供了一條可以嘗試的途徑：

Coverage 面板

4、Memory 面板

前端主要使用JavaScript代碼來處理業(yè)務(wù)邏輯，所以保證代碼在執(zhí)行過程中內(nèi)存的良性開銷對用戶的性能體驗(yàn)來說尤為重要，如果出現(xiàn)內(nèi)存泄漏，那么就可能會帶來網(wǎng)站應(yīng)用卡頓或崩潰的后果。

通過 Memory 面板可以快速生成當(dāng)前的堆內(nèi)存快照，或者查看內(nèi)存隨時(shí)間的變化情況。據(jù)此我們可以查看并發(fā)現(xiàn)可能出現(xiàn)內(nèi)存泄漏的環(huán)節(jié)。

5、Performance 面板

當(dāng)啟動了該工具面板的監(jiān)控功能后，與網(wǎng)站頁面的任何交互所引發(fā)的資源請求、頁面渲染、函數(shù)執(zhí)行及GPU耗時(shí)等信息，都會按照時(shí)間線的維度記錄下來，然后據(jù)此定位并分析可能存在性能問題的環(huán)節(jié)及原因。

6、Performance monitor 面板

雖然使用Performance面板來進(jìn)行檢測能夠得到較為全面的性能數(shù)據(jù)，但依然存在兩個(gè)使用上的問題，即面板信息不夠直觀和數(shù)據(jù)的實(shí)時(shí)性不夠強(qiáng)。

Performance 面板

為了彌補(bǔ)這兩方面的不足，Chrome從64版本開始便在開發(fā)者工具中引入了Performance monitor面板，通過它讓我們可以實(shí)時(shí)監(jiān)控網(wǎng)站應(yīng)用運(yùn)行過程中，諸如CPU占用率、JavaScript內(nèi)存使用大小、內(nèi)存中掛的DOM節(jié)點(diǎn)數(shù)、JavaScript事件監(jiān)聽次數(shù)及頁面發(fā)生重繪與重排的處理時(shí)間等信息。

據(jù)此如果我們發(fā)現(xiàn)，當(dāng)與頁面的交互過程中出現(xiàn)某項(xiàng)指標(biāo)有較為陡峭的增長，就意味著可能有影響性能體驗(yàn)的風(fēng)險(xiǎn)存在。

下圖中出現(xiàn)的明顯波動是執(zhí)行刷新頁面操作所產(chǎn)生的，可觀察到JavaScript堆內(nèi)存大小與DOM節(jié)點(diǎn)數(shù)的指標(biāo)都有一個(gè)明顯的斷崖式下跌，這正是刷新操作清除了原有DOM節(jié)點(diǎn)后，還未重新渲染出新節(jié)點(diǎn)的時(shí)間點(diǎn)。

7、PageSpeed Insights

這是Google官方推出的用于檢測網(wǎng)站頁面加載性能的自動化工具，它能夠針對移動設(shè)備和桌面設(shè)備分別進(jìn)行檢測并生成相應(yīng)的優(yōu)化改進(jìn)報(bào)告。其使用方式非常簡單，可直接打開工具主頁面，輸入所要檢測的目標(biāo)站點(diǎn)URL并單擊“分析”按鈕開始分析，稍等一段時(shí)間就可以得到性能報(bào)告。

8、WEBPAGETEST

WEBPAGETEST是一款非常專業(yè)的Web頁面性能分析工具，它可以對檢測分析的環(huán)境配置進(jìn)行高度自定義化，內(nèi)容包括測試節(jié)點(diǎn)的物理位置、設(shè)備型號、瀏覽器版本、網(wǎng)絡(luò)條件和檢測次數(shù)等，除此之外，它還提供了目標(biāo)網(wǎng)站應(yīng)用于競品之間的性能比較，以及查看網(wǎng)絡(luò)路由情況等多種維度下的測試工具。

2、Lighthouse 詳解

1、Chrome 控制臺直接使用

2、Nodejs 命令行

使用Nodejs命令行的方式，首先需要通過npm或yarn進(jìn)行Lighthouse模塊包的全局安裝，安裝命令如下：

// 使用 npm 全局安裝
npm install -g lighthouse
// 使用 yarn 安裝
yarn global add lighthouse

安裝好之后便可使用Lighthouse命令來生成目標(biāo)網(wǎng)站的性能檢測報(bào)告，通過添加執(zhí)行參數(shù)還可控制報(bào)告輸出的格式，有HTML和JSON兩種格式可以選擇。

比如：

lighthouse https://www.baidu.com/ -output-path=./report.json -ourput json

雖然這種方式不如使用Chrome開發(fā)者工具簡便直接，但它帶來的好處是能夠?qū)⒃拘枰謩犹幚淼臋z測過程，納入持續(xù)集成的工作范疇中，對網(wǎng)站性能進(jìn)行周期性自動化檢測，并監(jiān)控檢測報(bào)告中的關(guān)鍵指標(biāo)數(shù)據(jù)，當(dāng)出現(xiàn)超過閾值的數(shù)據(jù)時(shí)，以郵件或其他通信工具的方式通知開發(fā)者及時(shí)優(yōu)化。

3、性能狀況

關(guān)于性能狀況部分的檢測結(jié)果，Lighthouse給出的信息包括：檢測得分、性能指標(biāo)、優(yōu)化建議、診斷結(jié)果及已通過的性能。

1、檢測得分

經(jīng)過檢測，Lighthouse會對上述五個(gè)維度給出一個(gè)0～100的評估得分，如果沒有分?jǐn)?shù)或得分為0，則很有可能是檢測過程發(fā)生了錯(cuò)誤，比如網(wǎng)絡(luò)連接狀況異常等；如果得分能達(dá)到90分以上，則說明網(wǎng)站應(yīng)用在該方面的評估表現(xiàn)符合最佳實(shí)踐。

Lighthouse 檢測得分

關(guān)于如何得到這個(gè)評估得分，Lighthouse首先會獲得關(guān)于評估指標(biāo)的原始性能數(shù)據(jù)，然后根據(jù)指標(biāo)權(quán)重進(jìn)行加權(quán)計(jì)算，最后以其數(shù)據(jù)庫中大量的評估結(jié)果進(jìn)行對數(shù)正態(tài)分布的映射并計(jì)算最終得分。

2、性能指標(biāo)

關(guān)于性能指標(biāo)有以下六個(gè)關(guān)鍵的數(shù)據(jù)：首次內(nèi)容繪制時(shí)間(FCP)、首次有效繪制時(shí)間(FMP)、速度指數(shù)、首次CPU閑置時(shí)間、可交互前的耗時(shí)(TTI)及首次輸入延遲(FID)。性能指標(biāo)評估結(jié)果如圖：

(1)首次內(nèi)容繪制時(shí)間，指的是當(dāng)用戶瀏覽到網(wǎng)站頁面后，瀏覽器首次呈現(xiàn)出DOM元素內(nèi)容所花費(fèi)的時(shí)間，DOM內(nèi)容包括文本、圖像、SVG或非空白的〈canvas〉標(biāo)簽等，但iframe中的內(nèi)容繪制并不會考慮在內(nèi)。

對于該性能指標(biāo)評分的計(jì)算方法是這樣的：Lighthouse會根據(jù)網(wǎng)站實(shí)際的FCP時(shí)間與存檔中大量頁面的FCP時(shí)間進(jìn)行對比計(jì)算然后得出，例如約有90%的網(wǎng)站能在3s內(nèi)完成FCP的工作，我們目標(biāo)網(wǎng)站的FCP時(shí)間也是3s，那么FCP指標(biāo)的得分就是90。與此類似，接下來的五個(gè)性能指標(biāo)也是同樣的計(jì)算方法。

(2)首次有效繪制時(shí)間，這個(gè)指標(biāo)衡量的是用戶看到網(wǎng)站頁面主要內(nèi)容所花費(fèi)的時(shí)間，通常會和首次內(nèi)容繪制時(shí)間在數(shù)值上較為接近，但它還包含了iframe中內(nèi)容的渲染繪制。這里需要注意從Lighthouse 6.0版本開始不再推薦使用FMP指標(biāo)來進(jìn)行性能評估，其主要原因是FMP對頁面加載中的細(xì)微差別過于敏感，并且比較依賴于特定瀏覽器的實(shí)現(xiàn)細(xì)節(jié)，這就意味著它很難在所有Web瀏覽器中實(shí)現(xiàn)標(biāo)準(zhǔn)化。

(3)速度指數(shù)，用來衡量頁面加載過程中內(nèi)容可視化顯式的速度，即Lighthouse會檢測并捕獲頁面加載過程中每一幀之間的視覺變化進(jìn)度，然后使用Nodejs的speedline模塊包來生成相應(yīng)的評估得分。

(4)首次CPU閑置時(shí)間，指的是從頁面加載至主線程靜默且可進(jìn)行交互輸入的時(shí)間，只需頁面處于視窗中的大部分UI元素能夠交互即可，不要求全部元素都可交互。從Lighthouse 6.0版本開始也不建議使用該指標(biāo)，因?yàn)樗c接下來將要介紹的可交互前的耗時(shí)指標(biāo)相比，雖然提供了一些額外的衡量信息，但其差異并不足以為此設(shè)置兩個(gè)相似的指標(biāo)。

(5)可交互前的耗時(shí)，這是一個(gè)非常重要的性能指標(biāo)，如果網(wǎng)站頁面通過延遲可交互性為代價(jià)，來提高渲染出首屏頁面的速度，則可能會造成的結(jié)果是：網(wǎng)站頁面看似已經(jīng)準(zhǔn)備就緒，但嘗試與之交互時(shí)，卻得不到任何響應(yīng)的糟糕體驗(yàn)，比如過度延遲了一些JavaScript腳本的加載。

(6)首次輸入延遲，指的是用戶首次與網(wǎng)站頁面進(jìn)行交互開始到瀏覽器給出實(shí)際響應(yīng)之間的時(shí)間。這是一個(gè)以用戶為中心考量的性能指標(biāo)，如同F(xiàn)CP關(guān)注的是網(wǎng)站內(nèi)容首次被渲染出來的訪問體驗(yàn)，FID關(guān)注的是給予用戶及時(shí)反饋的使用體驗(yàn)，那么確保網(wǎng)站的高響應(yīng)速度、低交互延遲必然能夠給用戶留下良好的第一印象，也只有當(dāng)用戶愿意持續(xù)瀏覽網(wǎng)站或重復(fù)訪問時(shí)，網(wǎng)站的價(jià)值才能體現(xiàn)出來。

如前所述，上述6種不同的指標(biāo)數(shù)據(jù)需要通過加權(quán)計(jì)算，才能得到關(guān)于性能的最終評分，所加的權(quán)值越大表示對應(yīng)指標(biāo)對性能的影響就越大。

3、優(yōu)化建議

為了方便開發(fā)者更快地進(jìn)行性能優(yōu)化，Lighthouse在給出關(guān)鍵性能指標(biāo)評分的同時(shí)，還提供了一些切實(shí)可行的優(yōu)化建議。

性能檢測優(yōu)化建議

這些建議按照優(yōu)化后預(yù)計(jì)能帶來的提升效果從高到低進(jìn)行排列，每一項(xiàng)展開又會有更加詳細(xì)的優(yōu)化指導(dǎo)建議，從上到下依次包括以下內(nèi)容:

(1)移除阻塞渲染的資源，部分JavaScript腳本文件和樣式表文件可能會阻塞系統(tǒng)對網(wǎng)站頁面的首次渲染，建議可將其以內(nèi)嵌的方式進(jìn)行引用，并考慮延遲加載。報(bào)告會將涉及需要優(yōu)化的資源文件排列在下面，每個(gè)文件還包括尺寸大小信息和優(yōu)化后預(yù)計(jì)提升首屏渲染時(shí)間的效果，據(jù)此可安排資源文件優(yōu)化的優(yōu)先級。

(2)預(yù)連接所要請求的源，提前建立與所要訪問資源之間的網(wǎng)絡(luò)連接，或者加快域名的解析速度都能有效地提高頁面的訪問性能。這里給出了兩種方案：一種是設(shè)置〈link rel=“preconnect”〉的預(yù)連接，另一種是設(shè)置〈link rel=“dns-prefetch”〉的DNS預(yù)解析。

(3)降低服務(wù)器端響應(yīng)時(shí)間，通常引起服務(wù)器響應(yīng)緩慢的原因有很多，因此也有許多改進(jìn)方法：比如升級服務(wù)器硬件以擁有更多的內(nèi)存或CPU，優(yōu)化服務(wù)器應(yīng)用程序邏輯以更快地構(gòu)建出所需的頁面或資源，以及優(yōu)化服務(wù)器查詢數(shù)據(jù)庫等

(4)適當(dāng)調(diào)整圖片大小，使用大小合適的圖片可節(jié)省網(wǎng)絡(luò)帶寬并縮短加載用時(shí)，此處的優(yōu)化建議通常對于本應(yīng)使用較小尺寸的圖片就可滿足需求，但卻使用了高分辨率的大圖，對此進(jìn)行適當(dāng)壓縮即可。

(5)移除未使用的CSS，這部分列出了未使用但卻被引入的CSS文件列表，可以將其刪除來降低對網(wǎng)絡(luò)帶寬的消耗，若需要對資源文件的內(nèi)部代碼使用率進(jìn)行進(jìn)一步精簡刪除，則可以使用Chrome開發(fā)者工具的Coverage面板進(jìn)行分析。

4、診斷結(jié)果

(1)對靜態(tài)資源文件使用高效的緩存策略，這里列出了所有靜態(tài)資源的文件大小及緩存過期時(shí)間，開發(fā)者可以根據(jù)具體情況進(jìn)行緩存策略的調(diào)整，比如延遲一些靜態(tài)資源的緩存期限來加快二次訪問時(shí)的速度。

部分靜態(tài)資源緩存情況

(2)減少主線程的工作，瀏覽器渲染進(jìn)程的主線程通常要處理大量的工作：如解析HTML構(gòu)建DOM，解析CSS樣式表文件并應(yīng)用指定的樣式，以及解析和執(zhí)行JavaScript文件，同時(shí)還需要處理交互事件，因此渲染進(jìn)程的主線程過忙很容易導(dǎo)致用戶響應(yīng)延遲的不良體驗(yàn)，Lighthouse給我們提供了這一環(huán)節(jié)網(wǎng)站頁面主線程對各個(gè)任務(wù)的執(zhí)行耗時(shí)，讓開發(fā)者可針對異常處理過程進(jìn)行有目標(biāo)的優(yōu)化：

(3)降低JavaScript腳本執(zhí)行時(shí)間，前端項(xiàng)目的邏輯基本都是依托于JavaScript執(zhí)行的，所以JavaScript執(zhí)行效率與耗時(shí)也會對頁面性能產(chǎn)生不小的影響，通過對這個(gè)維度的檢測可以發(fā)現(xiàn)執(zhí)行耗時(shí)過長的JavaScript文件，進(jìn)而針對性的優(yōu)化JavaScript解析、編譯和執(zhí)行的耗時(shí):

(4)避免存在較大尺寸網(wǎng)絡(luò)資源的請求。

(5)縮短請求深度，瀏覽器通常會對同一域名下的并發(fā)請求進(jìn)行限制，超過限制的請求會被暫時(shí)掛起，如果請求鏈的深度過長，則需要加載資源的總尺寸也會越大，這都會對頁面渲染性能造成很大影響。因此建議在進(jìn)行性能檢測時(shí)，對該維度進(jìn)行關(guān)注和及時(shí)優(yōu)化。

關(guān)鍵請求鏈延遲

5、已通過的性能

這部分列出的優(yōu)化項(xiàng)為該網(wǎng)站已通過的性能審核項(xiàng)：

已通過的性能審核

(1)延遲加載首屏視窗外的圖片，對首屏關(guān)鍵資源加載完畢后，延遲首屏外或處于隱藏狀態(tài)的圖片加載能夠有效縮短用戶可交互前的等待時(shí)間，提升用戶訪問體驗(yàn)。

(2)壓縮CSS文件，可降低網(wǎng)絡(luò)負(fù)載規(guī)模。

(3)壓縮JavaScript文件，可降低網(wǎng)絡(luò)負(fù)載規(guī)模。

(4)對圖片文件采用高效的編碼方式，經(jīng)過編碼優(yōu)化的圖片文件，不但其加載速度會更快，而且需要傳輸?shù)臄?shù)據(jù)規(guī)模也會越小。

(5)采用新一代的圖片文件格式，WebP、JPEG XR、JPEG 2000等較新的圖片文件格式通常比傳統(tǒng)的PNG或JPEG有更好的壓縮效果，能夠獲得更快的下載速度和更少的流量消耗，但使用的同時(shí)還需要注意對新格式的兼容性處理。

(6)開啟文本壓縮，對于文本資源，先壓縮再提供能夠最大限度地減少網(wǎng)絡(luò)傳輸?shù)目傋止?jié)數(shù)，常用的壓縮方式有g(shù)zip、deflate和brotli，至少采用其中一種即可。

(7)避免多次頁面重定向，過多的重定向會在網(wǎng)頁加載前造成延遲。

(8)預(yù)加載關(guān)鍵請求，通過〈link rel=“preload”〉來預(yù)先獲取在網(wǎng)頁加載后期需要請求的資源，這主要是為了充分利用網(wǎng)站運(yùn)行的間歇期。

(9)使用視頻格式提供動畫內(nèi)容，建議通過WebM或MPEG4提供動畫，來取代網(wǎng)站頁面中大型GIF的動畫。

(10)避免DOM的規(guī)模過大，如果DOM規(guī)模過大，則可能會導(dǎo)致消耗大量的內(nèi)存空間、過長的樣式計(jì)算耗時(shí)及較高的頁面布局重排代價(jià)。Lighthouse給出的參考建議是，頁面包含的DOM元素最好少于1500個(gè)，樹的深度盡量控制不要超過32層。

(11)確保在網(wǎng)頁字體加載期間文本內(nèi)容可見，使用CSS的font-display功能，來讓網(wǎng)站頁面中的文本在字體加載期間始終可見。

6、最佳實(shí)踐

建議開發(fā)者盡量遵從，最佳實(shí)踐審核項(xiàng)如圖：

(1)使用HTTP 2協(xié)議，HTTP 2協(xié)議提供了許多HTTP 1.1協(xié)議所不具備的新特性，比如二進(jìn)制分幀層、多路復(fù)用及服務(wù)器端推送，新特性會帶來新的性能提升。

(2)使用HTTPS協(xié)議，應(yīng)盡量使用HTTPS，即使是那些非敏感數(shù)據(jù)的網(wǎng)站頁面也應(yīng)如此，它能夠有效地防止入侵者對用戶信息進(jìn)行篡改和監(jiān)聽。

(3)使用被動監(jiān)聽，將觸摸事件和鼠標(biāo)滾輪事件監(jiān)聽器標(biāo)記為“passive”，能夠有效提升頁面的滾動性能。

(4)跨域鏈接是不安全的，在外部鏈接中增加rel=noopener或rel=noreferrer來改善性能和防范安全漏洞。

(5)避免使用document.write()，使用document.write()動態(tài)注入的外部腳本，可能會使頁面加載延遲數(shù)十秒。

(6)避免使用具有已知安全漏洞的前端庫，一些第三方腳本可能包含已知的安全漏洞，這將會很容易被入侵者識別并利用，Lighthouse檢測的過程會對此進(jìn)行排查，同時(shí)一些過期廢棄的API也會被排查出來。

(7)在瀏覽器控制臺中沒有錯(cuò)誤的日志信息，打印在瀏覽器控制臺上的錯(cuò)誤日志表示網(wǎng)站應(yīng)用存在未解決的問題，它們可能來自網(wǎng)絡(luò)請求失敗或一些其他瀏覽器異常，不管怎樣都不應(yīng)對此熟視無睹。

最佳實(shí)踐審核項(xiàng)

7、搜索引擎優(yōu)化

(1)文檔中應(yīng)包含〈title〉元素，圖片元素使用alt屬性，這條建議和提高可訪問性部分的相同，但目的不同。

(2)文檔中設(shè)置meta標(biāo)簽的描述信息，該信息會在搜索引擎查找出該網(wǎng)站后，以摘要的形式進(jìn)行展示。

(3)確保網(wǎng)站訪問狀態(tài)碼成功，HTTP狀態(tài)碼不成功的頁面可能不會被搜索引擎列出來。

3、Performance 詳解