裸奔的前端綠皮車
theme: smartblue
這將是一篇比較通俗的文章，首先會講講構建產品體驗的幾個要素（純屬個人胡謅），中間穿插性能優化的例子，鑑於本人文筆羞澀，所以很多地方“文字不夠，圖片來湊”，敬請諒解。
歡迎查看我寫的《前端性能優化小技巧》、《快速搭建全鏈路平台》《四個例子教你提高用户體驗》《前端應用性能應該採集那些指標數據》《web應用性能簡析》，
正文 前端就是用户體驗，是價值，是創造
從用户體驗層面，量“前端體”裁“成本衣”
前端就是產品經理,產品體驗前端義不容辭
前端本是產品的開發者，也是產品的體驗者，產品性能體驗義不容辭
卡頓依舊是衡量產品體驗的核心要素
2022年第二季度馬上結束了，各位前端大大是不是開始為下個季度的okr發愁啦，那你可算有福利啦，福利發放前先給大家講個短故事
故事1 尋尋覓覓冷冷清清，乍暖還寒時，頁面還在卡頓
``` 用户：“日誌查詢很慢啊”
研發or產品：我這裏不慢啊，網絡的原因吧。 ``` 這是用户經常反應的一個情況，就是頁面卡。但是因為設備不同、瀏覽器兼容、網絡快慢、產品設計等原因，開發或者研發很少能復現。
卡頓的元兇之一：長耗時任務
這裏不禁要反覆説到上一篇文章《對前端性能的小看法》中曾插播一條小知識，長耗時任務（long-task） long task顧名思義，是花費時間比較長的任務。long task直接影響產品體驗。
聰明的公司和團隊都會注意減少long task的數量，尤其注重在核心功能的long task的數量和耗時。
以某管理後台數據為例，將180天內的long task的數量按照時間排序
基本能看出：
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。下圖中紅色虛線以上的面積便是性能優化的空間
一蹴而就的腦袋熱拯救不了卡頓
性能優化這項任務是艱鉅而且漫長的，為此也有很多的嘗試和實踐，然而流於形式或者沒有計劃的一蹴，熱情消散或者團隊更換後更容易無疾而終，不過目前整體來看最讓人頭疼的是 - 對產品性能注重不到位子 - 產品性能與團隊績效關聯不緊密 - 產品性能無處下手。
OKR福利一：以頁面為維度設定基線、優化目標、拆分目標和計劃
上圖是針對某管理後台數據，以180天內的long task的數量進行排名，取top 10的頁面，基本能看出：
1. 前三個頁面的長耗時總數量均超過20萬次
2. 墊底的頁面的長耗時總數量也超過1萬次
這樣看或許不夠直觀，以百分比視圖看可能更清晰能夠看清
- 前三個頁面的長耗時總數量總計佔比超過60%
- 其餘所有頁面長耗時總數量分佈比較均勻
季度OKR來了
聰明的團隊的季度OKR：
- long task 頁面總數量降低20%
- Top 10 卡頓頁面中Top 1、2、3降低10%
前端性能指標那麼多，為什麼不是其他指標？
First Paint 首屏渲染不能作為產品體驗的構建要素
- 對於非ssr頁面來講，頁面的首屏渲染大概率是一個“\\”代碼片段渲染後空白（即便做了骨架屏也至多是灰色結構塊），這和用户實際需要的畫面可能大相徑庭。
- 即便是ssr頁面，首屏是所有頁面中一個頁面，不一定能代表產品體驗。
後台性能指標不能作為產品體驗的關鍵要素
頁面展示的數據以及絕大多數業務邏輯來自於後台，但是 1. 前端用户體驗絕大多數數據來源於後端，但後端平均響應一般不會100ms開外 2. 後台平均耗時等指標僅能反應後端接口響應的情況
網絡不能作為產品體驗的要素
雖然部分頁面以離線包或者pwa的形式展示給用户，但前端整體還停留在對網絡傳輸的依賴上。以某小程序在過去90的網絡類型為例：
從前端能拿到的網絡連接類型基本有：
- 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為記錄對象，統計時間來看，
錯誤是保證用户體驗的基本要素
用户：
從用户體驗層面，一般前端錯誤可能來自：設備、網絡、後端程序、數據錯誤
故事 2 錯誤的背後不只是是流失與不信任
``` 大客户銷售：“被客户diss了，一堆產品錯誤”
研發or產品：我沒看到錯誤啊。 ``` 以某一次幫朋友查看前端系統報錯為例，用户90內有三段明顯的前端報錯。以下是我的分析情況
經過上面的分析，基本能看出報錯源於前端代碼，所以下鑽進行分析
以上是簡單寫了一個總結建議，給到了朋友，也解決了前端的報錯問題
裸奔的前端綠皮車
福利二 收集哪些指標
這個朋友是幸運的，因為系統收集了相關指標等信息，然而很多二三線前端產品目前還是裸奔狀態。也許公司購買了業務相關的埋點服務，但是對性能和錯誤的投入整體近乎於零。舉個簡單例子，很多公司對以下這幾個指標收集很少 - JS錯誤數量 - JS錯誤率 - 資源錯誤數 - 資源錯誤率 - 首次渲染平均時間 - 頁面加載平均耗時 - 頁面慢加載次數 - 資源加載平均耗時 - LCP平均耗時（或P99/P90） - FCP平均耗時（或P99/P90） - CLS平均偏移（或P99/P90） 針對收集的指標書寫一定的觸發條件
寫在最後
文章都是胡説，產品體驗大多數還是要看頁面是否卡頓、是否報錯，所以提出卡頓是衡量產品體驗的核心要素，報錯是衡量產品體驗的基本要素。