1 寫在前面

我們在進行網站或者APP開發后，最擔心的就是用戶訪問時出現頁面卡頓、白屏等性能問題，嚴重影響用戶體驗。現在大公司都會在性能提升和優化上下大功夫，會設置個前端性能標準和開發預警監控平臺。那么前端性能優化一般比較瑣碎繁雜，我們應該如何將瑣碎的工作進行系統化呢?

2 性能優化流程

在進行性能優化處理前，我們首先得知道性能優化的相關流程，這樣我們嚴格按照流程進行處理即可。與此同時，指定優化實踐流程是確保信任也可以按照執行，這是優化成果得以長期保持的重要保障，也是我們后期維護的動力。

性能優化流程有：

1. 指標設定
2. 性能標準
3. 收益評估
4. 診斷清單
5. 優化手段
6. 性能立項
7. 性能實踐

指標設定和性能標準： 我們要選擇什么樣的指標作為風向標?設定指標后，就是確定性能標準即我們的性能優化目標是什么樣的?性能要優化到什么程度算是合適的?

收益評估： 當我們做出這些性能優化的處理時，其實是需要關聯產品目標進行收益評估，如果沒有收益做出這些改變就不存什么意義了。做性能優化是為了服務于產品、提升用戶體驗，而不是在進行重復無意義的造輪子。

診斷清單： 其實在我們在生產過程中，有很多性能問題并不是立刻能夠監聽到的，對此需要將我們編寫的業務代碼接入到性能監控預警平臺，根據性能標準給出診斷清單，方便我們進行后續的改進和優化。

優化手段： 在監控預警平臺給出我們代碼的診斷清單后，我們需要結合性能標準針對性能標準確定相應的優化手段。

性能立項： 我們進行性能項目立項時，是需要產品和后端同學的支持的，也是我們進行性能優化流程不可或缺的內容。

性能實踐： 經歷過性能優化的項目需要重新發起上線，并跟蹤進行效果評估，結合場景把這些項目成果以文檔或代碼的形式沉淀下來，方便我們后續的學習和總結經驗。

3 性能指標采集與上報

前面我們提到了性能優化的基本流程，其中重要環境就需要依賴于監控預警平臺，需要對性能采集以及上報進行可視化。那么我們現在就需要把前面提到的性能指標以代碼的形式進行實施落地，進行分解落地確保可以采集到發現的性能問題，然后再進行SDK封裝后集合統計埋點，最后根據實際情況，指定上報策略。具體的有：

1. 指標分解
2. 指標采集
3. SDK封裝
4. 統計埋點
5. 上報策略
6. 數據預處理

性能監控預警平臺主要分為：性能數據處理后臺、性能可視化展現前臺以及性能數據存儲三部分。

性能數據處理后臺：主要在性能采集數據上報到性能平臺后，對數據進行預處理、數據清晰和數據計算，然后生成前臺可視化所需數據。

性能可視化展示前臺：主要是對核心數據指標進行可視化展示，對性能數據波動進行監控，當指標超過某個監控閾值時，性能監控預警平臺會通過郵件或者短信以及其他通知形式給我們發送預警信息。

性能數據存儲：此部分主要是進行采集和上報的性能數據存儲，方便后續進行數據分析和數據可視化處理。

4 性能監控預警平臺

在我們的項目開發完畢后，在準備上線前一定要做性能專項測試，檢查下你采取的措施和性能優化預期是否一致。

在整個性能優化體系中，你覺得最開始要做的事情是哪一個?比如說，在你們公司開發的APP活動頁出現了加載數據卡頓的性能問題時，我們應該如何進行優化呢?

當然，首要的步驟是確定它的性能指標及其標準是什么?只有設定好了性能指標，知道了它的標準，后續我們才能知道圍繞它如何進行性能優化。

那么什么樣的指標是值得我們關注的呢?當然是圍繞著用戶進行服務和優化體驗的可衡量的數據，可衡量即是可以通過代碼來度量的，關注以用戶為中心的關鍵結果和真實體驗的。

關鍵結果：我們知道要關注用戶關心的信息，那么用戶到底關心的是什么呢?當用戶進入商品詳情頁面時，他當然關注的是這個商品怎么樣，具體到頁面上的就是商品描述、商品頭圖、商品價格、商品銷量以及如何購買按鈕等關鍵信息。

真實體驗：真實體驗當然是使用產品的感受，比如用戶進入列表頁，在滑動過程中頁面加載突然跳出一個彈窗，他會不會覺得煩躁呢?又比如我們在年底各大平臺都會有年度報告，那么如果用戶在進行滑動切換頁面視頻、動畫和音樂播放并不是那么的流暢，這就會對產品預期想要得到的效果大打折扣。

5 性能優化關鍵指標設定及標準

在性能優化關鍵指標方面，當前業界主要集中在加載方面，特別是頁面的白屏時間和首屏時間。除了手動采集埋點上報外，還可以自動化采集上報，但是交互性和視覺穩定性關鍵指標，業界還在探索中，沒有達成統一的衡量標準，因此當前必須進行手動采集。

加載：就是在進入頁面時，頁面從白頁加載到顯示的載入過程。在你打開網站頁面時，你會發現有的網站首頁上的文字、圖片出現得很緩慢，但是有的加載有很快，這個內容出現的過程就是加載過程。

視覺穩定性指標：CLS(Cumulative Layout Shift)也就是布局偏移量，它是指頁面從一幀切換到另外一幀時，視線中不穩定元素的偏移情況。當前視覺穩定性指標CLS比較前沿，它的采集方法除了依賴Google的Lighthouse做本地采集，沒有更好的處理方案。比如說：你正要點擊頁面購買鏈接的時候，原先的位置突然插入了一個9.9包郵搶購的廣告，那么用戶就點進了商品廣告頁面，你說尷尬不?

交互方面指標：FID指標(First Input Delay，首次輸入延遲)指標必須盡量小于100ms，PSI(Perceptual Speed Index，視覺變化率)衡量標準是小于20%。

白屏時間：指的是從輸入內容回車(包括刷新、跳轉等方式)后到頁面開始出現第一個字符的時間，標準時間是300ms。

首屏時間：首屏時間的計算是”首屏時間=白屏時間+渲染時間“。首屏加載是被討論最多的話題,一方面web 前端首屏的加載性能的確普遍較差,另一方面,首屏的加載速度至關重要,很多時候過長的白屏會導致用戶還沒有體驗到網站功能的時候就流失了,首屏速度是用戶留存的關鍵點。

• 從重要性角度看，在用戶打開頁面后第一眼看到的內容是非常重要的，比如電商頁面的頭圖、商品價格、購買按鈕等。這些內容即使在最惡劣的網絡環境下，也要確保用戶能夠看到。
• 從體驗完整性角度看，進入頁面后先是白屏，隨著第一個字符加載到首屏內容顯示結束，我們才會認為加載完畢，用戶可以使用了。

首屏時間的標準，最初只是根據這個頁面對時間的敏感度進行判定的，主要以用戶平均首屏加載時間進行計算的，并沒有詳細區分2G/3G/4G/wifi這些網絡環境。

注意：最佳：白屏<1s，首屏<1.5s，onload<3s

首屏時間在1s內，用戶就會感覺加載速度很快，如果超過2.5s就會感到很慢。在1s內打開頁面，人們對于這么短的時間敏感度就不是很明顯，感知不出10ms和50ms有啥區別。當到了2G/3G弱網環境，或者網絡不穩定的環境條件下，用戶聯網加載的時間會變得特別長，嚴重影響整體指標。

對此，又有人們開始采用中位數坐正態分布，看分位值統計。P50(50分位值)、P90(90分位值)、P99(99分位值)，以P99為例，就是把所有首屏時間進行排序得到排名第99位的首屏時間作為指標，即P99。

后面又引入了指標：秒開率，即1s內打開用戶的占比。

首屏時間畢竟粒度還是比較粗的，如果首屏時間太長，白屏時間段，那么到底是哪里出現的問題呢?

• 首屏時間：可以拆分為白屏時間、數據接口響應時間、圖片加載資源時間等
• 白屏時間：數據接口響應時間可以直接從后端宿務中獲取，不需要前端再重復計算

6 參考文章

《前端性能優化方法與實踐》

7 寫在最后

本篇文章只是作為《前端性能優化筆記系列》文章的開篇，引導讀者對于性能優化體系有個更好的認知，了解相關的指標和指標，因為學習性能優化，并不是僅僅掌握一些優化技巧而已，更應該了解為什么要這樣做?