裸奔的前端綠皮車

語言: CN / TW / HK

theme: smartblue

這將是一篇比較通俗的文章,首先會講講構建產品體驗的幾個要素(純屬個人胡謅),中間穿插效能優化的例子,鑑於本人文筆羞澀,所以很多地方“文字不夠,圖片來湊”,敬請諒解。

歡迎檢視我寫的《前端效能優化小技巧》、《快速搭建全鏈路平臺》《四個例子教你提高使用者體驗》《前端應用效能應該採集那些指標資料》《web應用效能簡析》,

正文 前端就是使用者體驗,是價值,是創造

從使用者體驗層面,量“前端體”裁“成本衣”

前端就是產品經理,產品體驗前端義不容辭

前端本是產品的開發者,也是產品的體驗者,產品效能體驗義不容辭

卡頓依舊是衡量產品體驗的核心要素

2022年第二季度馬上結束了,各位前端大大是不是開始為下個季度的okr發愁啦,那你可算有福利啦,福利發放前先給大家講個短故事

故事1 尋尋覓覓冷冷清清,乍暖還寒時,頁面還在卡頓

``` 使用者:“日誌查詢很慢啊”

研發or產品:我這裡不慢啊,網路的原因吧。 ``` 這是使用者經常反應的一個情況,就是頁面卡。但是因為裝置不同、瀏覽器相容、網路快慢、產品設計等原因,開發或者研發很少能復現。

卡頓的元凶之一:長耗時任務

這裡不禁要反覆說到上一篇文章《對前端效能的小看法》中曾插播一條小知識,長耗時任務(long-task) long task顧名思義,是花費時間比較長的任務。long task直接影響產品體驗。

聰明的公司和團隊都會注意減少long task的數量,尤其注重在核心功能的long task的數量和耗時。 以某管理後臺資料為例,將180天內的long task的數量按照時間排序 long_task_180days.png 基本能看出: 1. 最長耗時任務250ms - 如果單一請求還涉及網路+後臺+資料庫,假設花費1s,那麼使用者至少花費1.25s - 頁面粗略按照1000ms / 60 ≈16.666ms一幀當做使用者能感受到的頁面不卡頓來講,頁面卡了 250 / 16.66 = 15 幀(不考慮其他時間) 2. 頁面平均卡頓在150ms-200ms之間 - 以50ms為基線,則頁面能優化空間至少為150ms-50ms=100ms,200ms-50ms=150ms,也就是頁面效能能提升的空間約為100ms-150ms。下圖中紅色虛線以上的面積便是效能優化的空間

baseline.png

一蹴而就的腦袋熱拯救不了卡頓

效能優化這項任務是艱鉅而且漫長的,為此也有很多的嘗試和實踐,然而流於形式或者沒有計劃的一蹴,熱情消散或者團隊更換後更容易無疾而終,不過目前整體來看最讓人頭疼的是 - 對產品效能注重不到位子 - 產品效能與團隊績效關聯不緊密 - 產品效能無處下手。

OKR福利一:以頁面為維度設定基線、優化目標、拆分目標和計劃

long_task.png 上圖是針對某管理後臺資料,以180天內的long task的數量進行排名,取top 10的頁面,基本能看出: 1. 前三個頁面的長耗時總數量均超過20萬次 2. 墊底的頁面的長耗時總數量也超過1萬次 這樣看或許不夠直觀,以百分比檢視看可能更清晰能夠看清

image.png

  1. 前三個頁面的長耗時總數量總計佔比超過60%
  2. 其餘所有頁面長耗時總數量分佈比較均勻

季度OKR來了

聰明的團隊的季度OKR:

  1. long task 頁面總數量降低20%
  2. Top 10 卡頓頁面中Top 1、2、3降低10%

前端效能指標那麼多,為什麼不是其他指標?

First Paint 首屏渲染不能作為產品體驗的構建要素

  1. 對於非ssr頁面來講,頁面的首屏渲染大概率是一個“\
    \
    ”程式碼片段渲染後空白(即便做了骨架屏也至多是灰色結構塊),這和使用者實際需要的畫面可能大相徑庭。
  2. 即便是ssr頁面,首屏是所有頁面中一個頁面,不一定能代表產品體驗。

後臺效能指標不能作為產品體驗的關鍵要素

頁面展示的資料以及絕大多數業務邏輯來自於後臺,但是 1. 前端使用者體驗絕大多數資料來源於後端,但後端平均響應一般不會100ms開外 2. 後臺平均耗時等指標僅能反應後端介面響應的情況

網路不能作為產品體驗的要素

雖然部分頁面以離線包或者pwa的形式展示給使用者,但前端整體還停留在對網路傳輸的依賴上。以某小程式在過去90的網路型別為例: image.png 從前端能拿到的網路連線型別基本有: - wifi - 4G - 3G - 2G - slow-2G 不同的網路型別源於不同的指標,也對應了不同的使用場景,引用最早對不同型別的定義和解釋標準如下

ECT | Minimum RTT (ms) | Maximum downlink (Kbps) | 解釋 | | --------- | ---------------- | ----------------------- | -------------------------------------------------------------------------------------------------------- | | slow-2g | 2000 | 50 | 文字資訊 | | 2g | 1400 | 70 | 小圖片 | | 3g | 270 | 700 | 部分高清圖片/音訊影片等大資料量| | 4g | 0 | ∞ | 高清音影片等超大資料量

對於3g型別能檢視高清圖片、音影片等場景只能呵呵了。3g場景下就是一線大廠也要一命嗚呼。

前端綠皮火車

假設北京的我們要去保定出差(假設疫情允許)。正常情況下我們需要先做地鐵到火車站,然後做火車站到保定。地鐵的部分好比後臺部分,火車部分是前端體驗部分,你做的是綠皮火車票還是高鐵火車票,這個差別能不大嗎?你以為這個例子誇張,然而實際是這輛前端綠皮車,可能還是燒煤的,整體來看,目前前端數量少、投入偏低是制約產品體驗的第一因素,在4G條件下,如果在保留各家網站快取策略的條件下,以淘寶、京東、百度、汽車之家、懂車帝、貝殼、知乎、頭條、小米商城為物件,如果把domContentLoaded為記錄物件,統計時間來看,

image.png

錯誤是保證使用者體驗的基本要素

使用者:

從使用者體驗層面,一般前端錯誤可能來自:裝置、網路、後端程式、資料錯誤

故事 2 錯誤的背後不只是是流失與不信任

``` 大客戶銷售:“被客戶diss了,一堆產品錯誤”

研發or產品:我沒看到錯誤啊。 ``` 以某一次幫朋友檢視前端系統報錯為例,使用者90內有三段明顯的前端報錯。以下是我的分析情況

image.png

image.png

經過上面的分析,基本能看出報錯源於前端程式碼,所以下鑽進行分析

image.png

image.png

image.png

以上是簡單寫了一個總結建議,給到了朋友,也解決了前端的報錯問題

裸奔的前端綠皮車

福利二 收集哪些指標

這個朋友是幸運的,因為系統收集了相關指標等資訊,然而很多二三線前端產品目前還是裸奔狀態。也許公司購買了業務相關的埋點服務,但是對效能和錯誤的投入整體近乎於零。舉個簡單例子,很多公司對以下這幾個指標收集很少 - JS錯誤數量 - JS錯誤率 - 資源錯誤數 - 資源錯誤率 - 首次渲染平均時間 - 頁面載入平均耗時 - 頁面慢載入次數 - 資源載入平均耗時 - LCP平均耗時(或P99/P90) - FCP平均耗時(或P99/P90) - CLS平均偏移(或P99/P90) 針對收集的指標書寫一定的觸發條件

image.png

寫在最後

文章都是胡說,產品體驗大多數還是要看頁面是否卡頓、是否報錯,所以提出卡頓是衡量產品體驗的核心要素,報錯是衡量產品體驗的基本要素。