We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
随着组织内的业务越来越多，前端项目起的越来越多。在旧年8月份，组织内对前端进行了一个聚合，将原本散落在各个业务的前端做了一个聚合，将原本各个业务团队的前端er变成了一个大的组别。
新官上任三把火，原本各个业务线的前端核心OKR是服务好业务，但是如果这样聚合之后还是这样学的话那就跟聚合前没啥两样，于是就得搞点新的东西出来，于是参考部门内的数据治理的健康分（数据的治理健康分，大致原理是对数据库的索引、数据量这些做一个指标性的统计，然后计算一个分数出来）前端侧也做了一个健康分的体系。
对整个页面来说，可以分为用户体验相关、技术指标，其中用户体验可以分为 渲染、加载、卡顿，技术指标就是报错具体分为 前端资源报错、前端脚本报错、后端接口报错、后端业务报错。
总分为100分，各部分占比为 （渲染【40%】、加载【20%】、卡顿【10%】，错误【20%】）
每个大指标的下的小指标，均分大指标的分值，在单个小指标的分值曲线上，我们做了一个分段，一共分为4段，分别为 优秀，良好，待优化，不及格，其中 不及格 和 待优化 的得分趋势斜率我们设计的大一点，负责系统的小伙伴通过优化可以得到一个比较明显数值变化，进而增大他们优化的动力。
计算公式如下：
假设小指标总分为 x ，从优秀到不及格这 4 个阶段的分值为 0 - a 为优秀，a - b 为良好，b - c 为待优化，c - 999 为不及格
在我们统计到的数据里，以LCP为例子，我们一个项目，一天的数据情况差别还是蛮大的，以其中一个项目为例，x总上报条数 23518 最小 197.20 最大 120,826.05，明显这两者都有点像异常值，在平均数的计算中，总是会将这些看起来有问题的异常数据进行平均，这样就比较容易忽视一些问题
这种情况用 分位数 就比较合适了，在实践中，我们使用了两个分位，P75 和 P95。
这是一个很成熟的领域了，在用 chrome 的 lighthouse 的时候，可以看到，所以在设计上我们直接用 Web Vitals 来做
以下三个指标，在 Web Vitals 已经给出了等级划分了，我们在其 3段的基础上，将良好的部分进行了切割，形成了4段
使用浏览器性监测API（PerformanceResourceTiming，type=js，css，image）的duration值
使用浏览器性监测API（PerformanceResourceTiming，type=xhr，fetch）的duration值
在浏览器执行超过 50ms 的任务记为长任务，长任务会导致页面渲染进程阻塞从而丢帧，长任务耗时越长反映用户体验越不流程
使用浏览器性监测API（PerformanceObserver）中 entryTypes: ["longtask"] 值
页面错误有些可能不会影响直接的用户体验，有些则可能导致用户的交互直接失败，算是一个很重要的技术指标
在实践中我们分成这4个错误率
(count(error = 1) / pv) where type = 'html'
(count(httpcode = success) / count(1)) where type = css、js、image
(count(httpcode = success) / count(1)) where type = xhr，fetch
(count(bussinesscode = success) / count(1)) where type = xhr，fetch
The text was updated successfully, but these errors were encountered:
百分位数值——服务响应时间的重要衡量指标
Sorry, something went wrong.
No branches or pull requests
背景
随着组织内的业务越来越多，前端项目起的越来越多。在旧年8月份，组织内对前端进行了一个聚合，将原本散落在各个业务的前端做了一个聚合，将原本各个业务团队的前端er变成了一个大的组别。
新官上任三把火，原本各个业务线的前端核心OKR是服务好业务，但是如果这样聚合之后还是这样学的话那就跟聚合前没啥两样，于是就得搞点新的东西出来，于是参考部门内的数据治理的健康分（数据的治理健康分，大致原理是对数据库的索引、数据量这些做一个指标性的统计，然后计算一个分数出来）前端侧也做了一个健康分的体系。
设计
对整个页面来说，可以分为用户体验相关、技术指标，其中用户体验可以分为 渲染、加载、卡顿，技术指标就是报错具体分为 前端资源报错、前端脚本报错、后端接口报错、后端业务报错。
总分为100分，各部分占比为 （渲染【40%】、加载【20%】、卡顿【10%】，错误【20%】）
每个大指标的下的小指标，均分大指标的分值，在单个小指标的分值曲线上，我们做了一个分段，一共分为4段，分别为 优秀，良好，待优化，不及格，其中 不及格 和 待优化 的得分趋势斜率我们设计的大一点，负责系统的小伙伴通过优化可以得到一个比较明显数值变化，进而增大他们优化的动力。
计算公式如下：
假设小指标总分为 x ，从优秀到不及格这 4 个阶段的分值为 0 - a 为优秀，a - b 为良好，b - c 为待优化，c - 999 为不及格
平均数 OR 分位数
在我们统计到的数据里，以LCP为例子，我们一个项目，一天的数据情况差别还是蛮大的，以其中一个项目为例，x总上报条数 23518 最小 197.20 最大 120,826.05，明显这两者都有点像异常值，在平均数的计算中，总是会将这些看起来有问题的异常数据进行平均，这样就比较容易忽视一些问题
这种情况用 分位数 就比较合适了，在实践中，我们使用了两个分位，P75 和 P95。
渲染
这是一个很成熟的领域了，在用 chrome 的 lighthouse 的时候，可以看到，所以在设计上我们直接用 Web Vitals 来做
以下三个指标，在 Web Vitals 已经给出了等级划分了，我们在其 3段的基础上，将良好的部分进行了切割，形成了4段
LCP
INP
CLS
加载
前端静态资源加载
使用浏览器性监测API（PerformanceResourceTiming，type=js，css，image）的duration值
后端接口耗时
使用浏览器性监测API（PerformanceResourceTiming，type=xhr，fetch）的duration值
卡顿
页面长任务耗时
在浏览器执行超过 50ms 的任务记为长任务，长任务会导致页面渲染进程阻塞从而丢帧，长任务耗时越长反映用户体验越不流程
使用浏览器性监测API（PerformanceObserver）中 entryTypes: ["longtask"] 值
报错
页面错误有些可能不会影响直接的用户体验，有些则可能导致用户的交互直接失败，算是一个很重要的技术指标
在实践中我们分成这4个错误率
前端脚本页面错误率
(count(error = 1) / pv) where type = 'html'
静态资源http状态码页面错误率
(count(httpcode = success) / count(1)) where type = css、js、image
后端接口http状态码页面错误率
(count(httpcode = success) / count(1)) where type = xhr，fetch
后端接口自定义业务状态码页面错误率
(count(bussinesscode = success) / count(1)) where type = xhr，fetch
The text was updated successfully, but these errors were encountered: