这将是一篇比较通俗的文章，首先会讲讲构建产品体验的几个要素（纯属个人胡诌），中间穿插性能优化的例子，鉴于本人文笔羞涩，所以很多地方“文字不够，图片来凑”，敬请谅解。
欢迎查看我写的《前端性能优化小技巧》、《快速搭建全链路平台》《四个例子教你提高用户体验》《前端应用性能应该采集那些指标数据》《web应用性能简析》，
正文 前端就是用户体验，是价值，是创造
从用户体验层面，量“前端体”裁“成本衣”
前端就是产品经理,产品体验前端义不容辞
前端本是产品的开发者，也是产品的体验者，产品性能体验义不容辞
卡顿依旧是衡量产品体验的核心要素
2022年第二季度马上结束了，各位前端大大是不是开始为下个季度的okr发愁啦，那你可算有福利啦，福利发放前先给大家讲个短故事
故事1 寻寻觅觅冷冷清清，乍暖还寒时，页面还在卡顿
用户：“日志查询很慢啊”
研发or产品：我这里不慢啊，网络的原因吧。
这是用户经常反应的一个情况，就是页面卡。但是因为设备不同、浏览器兼容、网络快慢、产品设计等原因，开发或者研发很少能复现。
卡顿的元凶之一：长耗时任务
这里不禁要反复说到上一篇文章《对前端性能的小看法》中曾插播一条小知识，长耗时任务（long-task） long task顾名思义，是花费时间比较长的任务。long task直接影响产品体验。
聪明的公司和团队都会注意减少long task的数量，尤其注重在核心功能的long task的数量和耗时。 以某管理后台数据为例，将180天内的long task的数量按照时间排序 基本能看出：
- 最长耗时任务250ms
- 如果单一请求还涉及网络+后台+数据库，假设花费1s，那么用户至少花费1.25s
- 页面粗略按照1000ms / 60 ≈16.666ms一帧当做用户能感受到的页面不卡顿来讲，页面卡了 250 / 16.66 = 15 帧（不考虑其他时间）
- 页面平均卡顿在150ms-200ms之间
- 以50ms为基线，则页面能优化空间至少为150ms-50ms=100ms，200ms-50ms=150ms，也就是页面性能能提升的空间约为100ms-150ms。下图中红色虚线以上的面积便是性能优化的空间
一蹴而就的脑袋热拯救不了卡顿
性能优化这项任务是艰巨而且漫长的，为此也有很多的尝试和实践，然而流于形式或者没有计划的一蹴，热情消散或者团队更换后更容易无疾而终，不过目前整体来看最让人头疼的是
- 对产品性能注重不到位子
- 产品性能与团队绩效关联不紧密
- 产品性能无处下手。
OKR福利一：以页面为维度设定基线、优化目标、拆分目标和计划
上图是针对某管理后台数据，以180天内的long task的数量进行排名，取top 10的页面，基本能看出：
- 前三个页面的长耗时总数量均超过20万次
- 垫底的页面的长耗时总数量也超过1万次
这样看或许不够直观，以百分比视图看可能更清晰能够看清
- 前三个页面的长耗时总数量总计占比超过60%
- 其余所有页面长耗时总数量分布比较均匀
季度OKR来了
聪明的团队的季度OKR：
- long task 页面总数量降低20%
- Top 10 卡顿页面中Top 1、2、3降低10%
前端性能指标那么多，为什么不是其他指标？
First Paint 首屏渲染不能作为产品体验的构建要素
- 对于非ssr页面来讲，页面的首屏渲染大概率是一个“<div id="app"></div>”代码片段渲染后空白（即便做了骨架屏也至多是灰色结构块），这和用户实际需要的画面可能大相径庭。
- 即便是ssr页面，首屏是所有页面中一个页面，不一定能代表产品体验。
后台性能指标不能作为产品体验的关键要素
页面展示的数据以及绝大多数业务逻辑来自于后台，但是
- 前端用户体验绝大多数数据来源于后端，但后端平均响应一般不会100ms开外
- 后台平均耗时等指标仅能反应后端接口响应的情况
网络不能作为产品体验的要素
虽然部分页面以离线包或者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）
针对收集的指标书写一定的触发条件
写在最后
文章都是胡说，产品体验大多数还是要看页面是否卡顿、是否报错，所以提出卡顿是衡量产品体验的核心要素，报错是衡量产品体验的基本要素。