1 寫在前面
我們在進行網(wǎng)站或者APP開發(fā)后，最擔心的就是用戶訪問時出現(xiàn)頁面卡頓、白屏等性能問題，嚴重影響用戶體驗。現(xiàn)在大公司都會在性能提升和優(yōu)化上下大功夫，會設置個前端性能標準和開發(fā)預警監(jiān)控平臺。那么前端性能優(yōu)化一般比較瑣碎繁雜，我們應該如何將瑣碎的工作進行系統(tǒng)化呢?
2 性能優(yōu)化流程
在進行性能優(yōu)化處理前，我們首先得知道性能優(yōu)化的相關流程，這樣我們嚴格按照流程進行處理即可。與此同時，指定優(yōu)化實踐流程是確保信任也可以按照執(zhí)行，這是優(yōu)化成果得以長期保持的重要保障，也是我們后期維護的動力。
性能優(yōu)化流程有：
- 指標設定
- 性能標準
- 收益評估
- 診斷清單
- 優(yōu)化手段
- 性能立項
- 性能實踐
指標設定和性能標準： 我們要選擇什么樣的指標作為風向標?設定指標后，就是確定性能標準即我們的性能優(yōu)化目標是什么樣的?性能要優(yōu)化到什么程度算是合適的?
收益評估： 當我們做出這些性能優(yōu)化的處理時，其實是需要關聯(lián)產(chǎn)品目標進行收益評估，如果沒有收益做出這些改變就不存什么意義了。做性能優(yōu)化是為了服務于產(chǎn)品、提升用戶體驗，而不是在進行重復無意義的造輪子。
診斷清單： 其實在我們在生產(chǎn)過程中，有很多性能問題并不是立刻能夠監(jiān)聽到的，對此需要將我們編寫的業(yè)務代碼接入到性能監(jiān)控預警平臺，根據(jù)性能標準給出診斷清單，方便我們進行后續(xù)的改進和優(yōu)化。
優(yōu)化手段： 在監(jiān)控預警平臺給出我們代碼的診斷清單后，我們需要結(jié)合性能標準針對性能標準確定相應的優(yōu)化手段。
性能立項： 我們進行性能項目立項時，是需要產(chǎn)品和后端同學的支持的，也是我們進行性能優(yōu)化流程不可或缺的內(nèi)容。
性能實踐： 經(jīng)歷過性能優(yōu)化的項目需要重新發(fā)起上線，并跟蹤進行效果評估，結(jié)合場景把這些項目成果以文檔或代碼的形式沉淀下來，方便我們后續(xù)的學習和總結(jié)經(jīng)驗。
3 性能指標采集與上報
前面我們提到了性能優(yōu)化的基本流程，其中重要環(huán)境就需要依賴于監(jiān)控預警平臺，需要對性能采集以及上報進行可視化。那么我們現(xiàn)在就需要把前面提到的性能指標以代碼的形式進行實施落地，進行分解落地確?？梢圆杉桨l(fā)現(xiàn)的性能問題，然后再進行SDK封裝后集合統(tǒng)計埋點，最后根據(jù)實際情況，指定上報策略。具體的有：
- 指標分解
- 指標采集
- SDK封裝
- 統(tǒng)計埋點
- 上報策略
- 數(shù)據(jù)預處理
性能監(jiān)控預警平臺主要分為：性能數(shù)據(jù)處理后臺、性能可視化展現(xiàn)前臺以及性能數(shù)據(jù)存儲三部分。
性能數(shù)據(jù)處理后臺：主要在性能采集數(shù)據(jù)上報到性能平臺后，對數(shù)據(jù)進行預處理、數(shù)據(jù)清晰和數(shù)據(jù)計算，然后生成前臺可視化所需數(shù)據(jù)。
性能可視化展示前臺：主要是對核心數(shù)據(jù)指標進行可視化展示，對性能數(shù)據(jù)波動進行監(jiān)控，當指標超過某個監(jiān)控閾值時，性能監(jiān)控預警平臺會通過郵件或者短信以及其他通知形式給我們發(fā)送預警信息。
性能數(shù)據(jù)存儲：此部分主要是進行采集和上報的性能數(shù)據(jù)存儲，方便后續(xù)進行數(shù)據(jù)分析和數(shù)據(jù)可視化處理。
4 性能監(jiān)控預警平臺
在我們的項目開發(fā)完畢后，在準備上線前一定要做性能專項測試，檢查下你采取的措施和性能優(yōu)化預期是否一致。
在整個性能優(yōu)化體系中，你覺得最開始要做的事情是哪一個?比如說，在你們公司開發(fā)的APP活動頁出現(xiàn)了加載數(shù)據(jù)卡頓的性能問題時，我們應該如何進行優(yōu)化呢?
當然，首要的步驟是確定它的性能指標及其標準是什么?只有設定好了性能指標，知道了它的標準，后續(xù)我們才能知道圍繞它如何進行性能優(yōu)化。
那么什么樣的指標是值得我們關注的呢?當然是圍繞著用戶進行服務和優(yōu)化體驗的可衡量的數(shù)據(jù)，可衡量即是可以通過代碼來度量的，關注以用戶為中心的關鍵結(jié)果和真實體驗的。
關鍵結(jié)果：我們知道要關注用戶關心的信息，那么用戶到底關心的是什么呢?當用戶進入商品詳情頁面時，他當然關注的是這個商品怎么樣，具體到頁面上的就是商品描述、商品頭圖、商品價格、商品銷量以及如何購買按鈕等關鍵信息。
真實體驗：真實體驗當然是使用產(chǎn)品的感受，比如用戶進入列表頁，在滑動過程中頁面加載突然跳出一個彈窗，他會不會覺得煩躁呢?又比如我們在年底各大平臺都會有年度報告，那么如果用戶在進行滑動切換頁面視頻、動畫和音樂播放并不是那么的流暢，這就會對產(chǎn)品預期想要得到的效果大打折扣。
5 性能優(yōu)化關鍵指標設定及標準
在性能優(yōu)化關鍵指標方面，當前業(yè)界主要集中在加載方面，特別是頁面的白屏時間和首屏時間。除了手動采集埋點上報外，還可以自動化采集上報，但是交互性和視覺穩(wěn)定性關鍵指標，業(yè)界還在探索中，沒有達成統(tǒng)一的衡量標準，因此當前必須進行手動采集。
加載：就是在進入頁面時，頁面從白頁加載到顯示的載入過程。在你打開網(wǎng)站頁面時，你會發(fā)現(xiàn)有的網(wǎng)站首頁上的文字、圖片出現(xiàn)得很緩慢，但是有的加載有很快，這個內(nèi)容出現(xiàn)的過程就是加載過程。
視覺穩(wěn)定性指標：CLS(Cumulative Layout Shift)也就是布局偏移量，它是指頁面從一幀切換到另外一幀時，視線中不穩(wěn)定元素的偏移情況。當前視覺穩(wěn)定性指標CLS比較前沿，它的采集方法除了依賴Google的Lighthouse做本地采集，沒有更好的處理方案。比如說：你正要點擊頁面購買鏈接的時候，原先的位置突然插入了一個9.9包郵搶購的廣告，那么用戶就點進了商品廣告頁面，你說尷尬不?
交互方面指標：FID指標(First Input Delay，首次輸入延遲)指標必須盡量小于100ms，PSI(Perceptual Speed Index，視覺變化率)衡量標準是小于20%。
白屏時間：指的是從輸入內(nèi)容回車(包括刷新、跳轉(zhuǎn)等方式)后到頁面開始出現(xiàn)第一個字符的時間，標準時間是300ms。
首屏時間：首屏時間的計算是”首屏時間=白屏時間+渲染時間“。首屏加載是被討論最多的話題,一方面web 前端首屏的加載性能的確普遍較差,另一方面,首屏的加載速度至關重要,很多時候過長的白屏會導致用戶還沒有體驗到網(wǎng)站功能的時候就流失了,首屏速度是用戶留存的關鍵點。
- 從重要性角度看，在用戶打開頁面后第一眼看到的內(nèi)容是非常重要的，比如電商頁面的頭圖、商品價格、購買按鈕等。這些內(nèi)容即使在最惡劣的網(wǎng)絡環(huán)境下，也要確保用戶能夠看到。
- 從體驗完整性角度看，進入頁面后先是白屏，隨著第一個字符加載到首屏內(nèi)容顯示結(jié)束，我們才會認為加載完畢，用戶可以使用了。
首屏時間的標準，最初只是根據(jù)這個頁面對時間的敏感度進行判定的，主要以用戶平均首屏加載時間進行計算的，并沒有詳細區(qū)分2G/3G/4G/wifi這些網(wǎng)絡環(huán)境。
注意：最佳：白屏<1s，首屏<1.5s，onload<3s
首屏時間在1s內(nèi)，用戶就會感覺加載速度很快，如果超過2.5s就會感到很慢。在1s內(nèi)打開頁面，人們對于這么短的時間敏感度就不是很明顯，感知不出10ms和50ms有啥區(qū)別。當?shù)搅?G/3G弱網(wǎng)環(huán)境，或者網(wǎng)絡不穩(wěn)定的環(huán)境條件下，用戶聯(lián)網(wǎng)加載的時間會變得特別長，嚴重影響整體指標。
對此，又有人們開始采用中位數(shù)坐正態(tài)分布，看分位值統(tǒng)計。P50(50分位值)、P90(90分位值)、P99(99分位值)，以P99為例，就是把所有首屏時間進行排序得到排名第99位的首屏時間作為指標，即P99。
后面又引入了指標：秒開率，即1s內(nèi)打開用戶的占比。
首屏時間畢竟粒度還是比較粗的，如果首屏時間太長，白屏時間段，那么到底是哪里出現(xiàn)的問題呢?
- 首屏時間：可以拆分為白屏時間、數(shù)據(jù)接口響應時間、圖片加載資源時間等
- 白屏時間：數(shù)據(jù)接口響應時間可以直接從后端宿務中獲取，不需要前端再重復計算
6 參考文章
《前端性能優(yōu)化方法與實踐》
7 寫在最后
本篇文章只是作為《前端性能優(yōu)化筆記系列》文章的開篇，引導讀者對于性能優(yōu)化體系有個更好的認知，了解相關的指標和指標，因為學習性能優(yōu)化，并不是僅僅掌握一些優(yōu)化技巧而已，更應該了解為什么要這樣做?
原文鏈接：https://mp.weixin.qq.com/s/CNCu7obbWqOI4kMF6lN1cw
