一、背景

1.1.前端性能優化的業務意義

前端的本質價值是什么?

我認為是  給用戶創造良好的交互體驗 。 前端性能對用戶體驗、對業務跳失率的影響，在業界已有共識，不言而喻。 根據 Google 的數據，如果移動站點的加載時間超過 3 秒，53% 的用戶會放棄訪問。

加載時間從 1s 延長到 3s 時，跳失率增加32%

加載時間從 1s 延長到 5s 時，跳失率增加90%——用戶還沒看到辛苦優化的頁面，就走了一部分 。

（參考文末鏈接）

抵達率優化應該在轉化率之前， 用戶能夠正常訪問網頁，網頁的內容才能產生價值。 所以在優化著陸頁內容、提高轉化率之前，要先保障抵達率。 抵達率太低，哪怕頁面轉化100%，整體的轉化效果也會很差。

1.2. 測試把控難點

• 現在流行的，運營自行搭建頁面+自行多端投放 方式，使我們的不可控。
• 原先發現性能問題主要通過感受+性能跑測數據，或者運營以業務要挾、或者質疑受機器等因素影響、或者相互推諉主要瓶頸點，使優化無法落實。
• 部分性能優化困難，影響性能點比較復雜，實行優化的收益不可預知，也阻礙了優化的落實。

二、前端性能優化 測試視角的解法

很多人都以為，前端性能優化，重點在“前端”優化，“測試”很難起到主導作用。 試著換個角度，從整個研發團隊視角看，前端做運動員專項治理，測試做裁判員專項評測，這套機制，是否更能切實做到優化，達成的數據也更讓大家信賴？ 再者，測試不止局限于此，還可做隊醫、分析師。 。 。 。

2.1.可持續優化閉環

以下持續優化閉環，是我們摸索著實行了一年多，有效且高效的解法。

從上圖看，整個過程為：

step0、前端事先進行埋點，（一般前端做了sdk，直接引入即可）

step1、測試通過性能黑榜，發現最為突出的重點性能問題頁面（首屏平均時長&秒開率，PV&業務意義， 多項結合度量）

step2、協助前端一起專業分析問題頁面，找出性能瓶頸點

step3、前端更有策略地針對性治理

step4、查看性能趨勢變化，驗證優化效果

step5、假設已達到優化預期，或者有更糟糕的頁面把之前頁面擠下去，繼續關注黑榜前列的頁面（即跳到step1，繼續輪轉）

我們可以發現，測試通過發現、分析、驗證 三板斧，驅動推進頁面性能優化。

2.2.效果明顯

從2021年10月份開始迭代以來， 共發現了8類嚴重性能問題 。

包括：端外（支付寶）性能問題，外投&跨端性能問題，pha架構性能問題，運營不規范配置導致、其他業務原因導致的性能問題等。

并且快速有效，在業務方或其他同學提過來之前，我們都已經發現并有了分析，在優化節奏上更具有主動性。

三、性能問題的發現

通過線上用戶的真實采集，并制定能反應用戶體感的指標，進行性能黑榜和全局趨勢分析。

從重點單點角度，我們通過性能黑榜； 從整體視角，我們通過整體趨勢分析。

3.0.性能數據的采集

3.0.1.幾個名詞解釋

ARMS 前端 監控專注于對Web場景、小程序場景的監控，從頁面打開速度（測速）、頁面穩定性（JS診斷錯誤）和外部服務調用成功率（API）這三個方面監測Web和小程序頁面的健康度。

SLS 日志服務為Log、Metric、Trace等數據提供大規模、低成本、 實時 的平臺化服務。日志服務一站式提供數據采集、加工、查詢與分析、可視化、告警、消費與投遞等功能。

ODPS 即MaxCompute，是適用于 數據分析 場景的企業級SaaS模式云數據倉庫。

FBI 是阿里內的智能大數據分析和 可視化 平臺，下面的所有截圖都是在FBI平臺配置圖表而成，還未對外開放。

3.0.2.全過程

arms-sdk結合前端的自定義埋點，在海量用戶訪問的同時，就會自動上報數據到sls日志庫，整體過程如下圖：

• 針對H5搭建頁的埋點，使用通用方案，一次性埋點即可，前端后續無需額外埋。
• sls日志報表查實時數據，用于實時分析，實時驗證。
• ODPS數據長期存儲已計算完指標的數據，用于記錄、比較、趨勢分析。

3.1.性能指標的確定

3.1.1.統計范圍--用戶視角

所有前臺頁面，每個用戶每次瀏覽的有效數據（完全加載<15s 內有效）

指標的影響因子：從用戶視角，頁面流量越大，則對整體數據的影響越大（也就是權重越大）

這樣做的好處：流量越大數值越嚴重的，優化的效果（正反饋）越明顯，確定了治理性能問題的優先級。

3.1.2.三個指標

結合淘系、以及集團其他部門的

3.2.性能黑榜

為何要用性能黑榜來作為主要發現手段？我們通常可推理得：

• 排在性能黑榜前列的，必然是性能問題最突出的，相對方便分析

（可根據各自業務，加個樣本量的篩選，如我們看每日pv 10w以上的）

• 再結合樣本量（pv正相關）數據，樣本量非常大的，性能優化的收益必然也是非常大的
• 模塊化組件開發盛行的今天，優化某個模塊或場景的問題，收益點不僅僅在當前頁面，也在其他用了同樣模塊或場景的頁面
• 榜單形式，更能引起老板、對應前端負責同學、對用戶體驗關注的同學的重視

3.3.整體性能趨勢分析

整體趨勢分析，即是為在整體角度，看我們的頁面性能趨勢，它是重要的度量指標。

這里我們把所有的流量都納入，沒有頁面的區分， 為的是基于用戶維度，流量大的頁面權重自然會更大。

從上圖看，1月初到2月中旬的數據正在持續惡化，必須要采取措施治理！

四、性能問題的分析

（下文以2022年2月A頻道頁面為例，均為dummy仿造后數據，也不代表整體情況）

4.1.如何衡量性能問題嚴重性

衡量性能問題嚴重性，是為了讓大家意識到優化的必要性，以及急迫性

4.1.0.進入性能黑榜前幾名

同3.1.性能黑榜，不贅述

4.1.1.看完全加載時長分布

見下圖“可交互時長分布圖”，一個記錄代表一個用戶。

即使不去統計，我們都能很明顯的看出來，這個A頻道頁面：

<1.5s的比例很低

1.5~3s占比最大

>3s的比例相對而言很高，居然還有這么高比例在8s以上？

4.1.2.看時長分布比例

和開發說明問題嚴重性時，這個會很有代入感， 比如見下圖，10%的Android用戶在4.9s以上，是不是可以認為他們大部分都跳失了？

4.1.3.看和總體數據的對比

下圖不用算都能明顯發現，秒開率和 整體數據差異實在太大

4.2.分析性能瓶頸-分析思路

首先要明確，性能分析主要是給相關頁面的前端、開發同學看，給關心問題的測試同學看，所以我們可以拆分的更細節、更專業。 可以先分前端、后端2個大類：

4.3.分析性能瓶頸-前端環節

4.3.1.分終端分析

業務因素（具體不表），分終端是重點。

從可交互時長、秒開率、3秒+率、5秒+率，分別分析，都能論證--支付寶端問題更明顯。

4.3.2.分階段分析

下圖將t1~t9 每個階段打點情況可視化，并分析重點環節的差值（打點邏輯由前端定義）

見圖2可以明顯觀察到：

1、接口耗時太久，且2.12后變差明顯（可以去追溯下2.12發生了什么）；

2、LBS獲取耗時很久，高于平均1倍以上，而取lbs是A頻道頁的關鍵邏輯

4.3.3.分高中低端機分析

我們根據手淘的高中低端機評判標準，埋點獲得數據。 平均時長，高中低各自占比，以及低端時長分布（也可選中高端）。 下圖可發現，低端機比例很低（需要思考是否有必要重點優化）， 但低端機超過3秒以上的比例遠高于其他的（和總體的完全時間分布對比） 。

4.3.4.其他分析

包括：機型、系統等，可做參考

4.4.分析性能瓶頸-后端環節

4.4.1.后端接口分析

主要從后端維度來分析

• 服務端鏈路邏輯，需要另做具體分析
• 分頁面的處理邏輯，需要結合業務邏輯來看

這里可見，下圖盡管是開始發起請求-》收到請求的全過程，但也嚴重超標（幾乎是標準值的2倍）

4.4.2.網絡傳輸消耗分析

整個接口過程：

請求連接(apiConnect)--》服務端處理(apiRequest)--》數據下載(apiResponse)

細節不表了

4.5.分析結論關鍵思路

1、數據差值越大的，樣本量越多的，性能數據優化越明顯

2、結合業務意義

3、為前端分析提供方向，更細節分析，還是要依賴前端的專業分析

還是以A頻道為例， 從數據差值看，接口和lbs，和均值差異最大。 從樣本量看，支付寶 流量占有一定比例， 因此，我們優化的重點在： 接口、LBS、支付寶端。

五、性能問題的驗證

主要通過單頁面性能趨勢分析，主要2個作用

• 驗證性能優化效果，做到可量化
• 及時洞察到頁面性能向差的趨勢，更具有主動性

5.1.性能惡化及時反饋 

再如下圖，今年1月，一次業務需求，致使性能變差，通過每周定時性能報表發送群里，馬上發現。 推薦大家把性能趨勢圖，定時發送到群內，更及時發現。

5.2.性能優化效果驗證

參考鏈接： https://zhuanlan.zhihu.com/p/51673262

R語言編程基礎(U3010001)

R是用于統計分析、繪圖的語言和操作環境，屬于GNU系統的一個自由、免費、源代碼開放的軟件，它是一個用于統計計算和統計制圖的優秀工具。

R語言語法通俗易懂,很容易學會和掌握語言的語法。而且學會之后,我們可以編制自己的函數來擴展現有的語言。這也就是為什么它的更新速度比一般統計軟件,如SPSS、SAS等快得多。大多數最新的統計方法和技術都可以在R中直接得到。

點擊閱讀原文查看詳情。