这将是一篇比较通俗的文章，首先会讲讲构建产品体验的几个要素（纯属个人胡诌），中间穿插性能优化的例子，鉴于本人文笔羞涩，所以很多地方“文字不够，图片来凑”，敬请谅解。

欢迎查看我写的《前端性能优化小技巧》、《快速搭建全链路平台》《四个例子教你提高用户体验》《前端应用性能应该采集那些指标数据》《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万次 这样看或许不够直观，以百分比视图看可能更清晰能够看清

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的网络类型为例：

从前端能拿到的网络连接类型基本有：

• wifi
• 4G
• 3G
• 2G
• slow-2G 不同的网络类型源于不同的指标，也对应了不同的使用场景，引用最早对不同类型的定义和解释标准如下

对于3g类型能查看高清图片、音视频等场景只能呵呵了。3g场景下就是一线大厂也要一命呜呼。

前端绿皮火车

假设北京的我们要去保定出差（假设疫情允许）。正常情况下我们需要先做地铁到火车站，然后做火车站到保定。地铁的部分好比后台部分，火车部分是前端体验部分，你做的是绿皮火车票还是高铁火车票，这个差别能不大吗？你以为这个例子夸张，然而实际是这辆前端绿皮车，可能还是烧煤的，整体来看，目前前端数量少、投入偏低是制约产品体验的第一因素，在4G条件下，如果在保留各家网站缓存策略的条件下，以淘宝、京东、百度、汽车之家、懂车帝、贝壳、知乎、头条、小米商城为对象，如果把domContentLoaded为记录对象，统计时间来看，

错误是保证用户体验的基本要素

用户：

从用户体验层面，一般前端错误可能来自：设备、网络、后端程序、数据错误

故事 2 错误的背后不只是是流失与不信任

大客户销售：“被客户diss了，一堆产品错误”
研发or产品：我没看到错误啊。

以某一次帮朋友查看前端系统报错为例，用户90内有三段明显的前端报错。以下是我的分析情况

经过上面的分析，基本能看出报错源于前端代码，所以下钻进行分析

以上是简单写了一个总结建议，给到了朋友，也解决了前端的报错问题

裸奔的前端绿皮车

福利二 收集哪些指标

这个朋友是幸运的，因为系统收集了相关指标等信息，然而很多二三线前端产品目前还是裸奔状态。也许公司购买了业务相关的埋点服务，但是对性能和错误的投入整体近乎于零。举个简单例子，很多公司对以下这几个指标收集很少

• JS错误数量
• JS错误率
• 资源错误数
• 资源错误率
• 首次渲染平均时间
• 页面加载平均耗时
• 页面慢加载次数
• 资源加载平均耗时
• LCP平均耗时（或P99/P90）
• FCP平均耗时（或P99/P90）
• CLS平均偏移（或P99/P90） 针对收集的指标书写一定的触发条件

写在最后

文章都是胡说，产品体验大多数还是要看页面是否卡顿、是否报错，所以提出卡顿是衡量产品体验的核心要素，报错是衡量产品体验的基本要素。