数据包括性能指标、监控数据以及通过埋点得到的业务数据，而数据分析是体验优化的最后一环。   通过数据来量化当前的工作，从而证明工作是否高效，优化是否有效等问题。   量化的工作包括代码质量和业务数据。 ## 一、代码质量   代码质量的数据来源于思维导图中的性能指标和监控体系，包括 SLA、慢响应、前端错误、白屏和首屏时间等，以折线图的形式描述趋势变化。   因为我们组维护着大量的 Node 服务，所以指标中就会包含多个服务端数据。其中慢响应作为我们组的北极星指标。   所谓北极星指标，也叫第一关键指标，是指在产品的当前阶段与业务/战略相关的核心指标，一旦确立就像北极星一样指引团队向同一个方向前进。 **1）SLA**   SLA 是指服务质量保证，参考的指标是异常状态码接口占比，即报 500、502、503 和 504 的接口。   其中 500 是代码错误，我们可以通过日志做排查。我们公司要求 SLA 的值要至少达到 5 个 9，即 99.999XX%。   如果要实现 6 个 9，按照我们公司每日的体量，每天只能允许 4 个以内的接口异常，维护成本比较大。    在 500 的错误码中，监控接口占据了 94% 左右，主要是因为上传的数据量太大导致报错，服务端限制 1M，最终在上传时就做大小限制。   还有一个占据了 6.2% 的错误接口主要是逻辑不够严密，边界条件没有处理好，修复后就降到了 0。   502 是转发的后端服务不存在，503 是没有转发或服务挂起，如果大量报，可以去找下运维。   504 是由后端服务出问题导致的超时引起的，例如数据库因为一条耗时的查询语句而被挂起。 **2）慢响应**   慢响应是那些响应时间超过 2 秒的接口，在内部又将慢响应分为对外业务慢响应和对内后台慢响应，主要精力会放到对外业务上。   公司要求对外的慢响应占比要控制在万分之 2 以内，对内就比较松，只要不是很慢，可以操作就行。   造成慢响应的原因有一种是内部逻辑慢，另一种是受调用的接口影响而变慢。   第一种就可以我们自己解决，第二种就需要找协作组配合解决了。   有一个占了业务慢响应 67.4% 数量的监控列表接口，属于前者，在内部会查询一张 430W 的大表 6 次。   优化手段也很直接，就是减少查询次数，降到 1 次，慢响应次数一下子减少了 95%。   还有个举报接口，也属于前者，这张表也比较大，增加查询条件，触发索引，就立竿见影的把速度提上来了。   该慢响应次数一下子减少了 90%。这两个接口优化后，业务慢响应总占比从万分之 0.23 降低到万分之 0.1。   有一个内容审核的服务，由于架构缺陷导致优化成本很高，后面直接迁移后，后台慢响应占比从最高的万分之 98.13 降低到万分之 9.79。 **3）前端错误**   前端错误就是通过监控系统搜集到的错误日志，分为脚本错误和通信异常。   脚本错误就是 JavaScript 的异常，例如用 undefined 当对象读取属性。   一个项目中的脚本错误在修复后，从高峰的 4073 降低至246，减少了 93.96%，进一步的保障项目质量。   虽然也能搜集图像请求的错误，但是却不能获取到错误原因，可能是用了代理或静态服务器偶尔的波动。   曾经在内容审核的页面，有段时间每日上报的图像错误最高达到 28827，之后动态的将图像质量降低 70%，错误上报量从降低至 1641。   通信异常其实也是 500、502 和 504 接口，之前的接口异常数量会包括静态资源以及内部的服务调用。   而此处的通信异常只包含从客户端发起的那部分接口，可以简单理解为其子集，不过有时候发现 502 和 504 的统计两边会有略微差异。 **4）白屏和首屏时间**   白屏就是等待白屏的时间（FP），首屏更确切的说是首次有意义的内容加载时间（FMP）。   之前做过一套性能监控系统，白屏比较好计算，而首屏比较复杂，我们这边采用最简单的埋点的方式。   也就是手动的在某个阶段记录首屏时间，比较麻烦的是需要将线上页面逐个添加，不过也没多少个，所以还能接受这个笨办法。   以首屏为例，1 秒内占 72%左右，2 秒内占 19% 左右，若以 1.2 秒为边界的话，那优化的空间还是蛮大的。   初步排查后，发现主要慢在 DOM 解析，这让我蛮诧异的，经过 Chrome DevTools 的性能分析后，定位到了脚本尺寸上。   加载的脚本有点多，并且有一个 chunk-vendors.js 脚本还比较大，下载时间有点长。   因此在加载和运行时就会延长 DOM 的解析，影响白屏时间。 ## 二、业务数据   业务数据大多来源于分布在页面各处的埋点，经过数据分析后能得出各类报表，可以直观的查看业务是在增长还是下降亦或是持平。   在体验优化后，查看下相关数据的前后变化，就能知道此次优化是否成功了。   我们组的工作效率也是业务数据的一部分，但是这块比较难量化，不可能通过代码行数来判别，因此就想到了需求提测率和双月用户满意度评分。 **1）需求提测率**   公司每双月会开一次需求讨论会，罗列本双月的需求。   我会以这份列表为基础，自己再开一份在线列表，记录所有需求的状态，并且会将不在此列表中的零碎需求也记录。   这份列表有 5 列，包括需求名称、线上BUG数、功能点数量、状态和备注。   其中状态又包括设计、提测、上线、延期等，可以一眼就能反映出需求所处的阶段。   线上 BUG 数就是字面意思，而功能点数量是 QA 提供的，他们在写测试用例时就会有这个数据。   不过没多久，线上 BUG 数和功能点数量没有维护起来，因为很多管理后台需求经常都不写用例，而活动比较常规，结构差不多也就不会细写。   线上 BUG 数因为每次都比较少的，偶尔会有几个，所以也就不怎么写了。   我的需求提测率是按提测状态来统计，而不是上线状态。   因为有时候是需要多端联调的，经常会碰到协作方因为种种原因无法配合联调或延期。   提测是指 QA 可以验收需求，所以要说明此处的联调问题并不是指我们写好界面，然后等服务端给接口。   而是比如我们完成管理后台的前后端功能，提供数据源，服务端没有时间处理这批数据，类似于这种场景。 **2）双月用户满意度评分**   这是一张问卷调查，满分是 5 分，收集大家对我们组工作的反馈，对当前存在的问题可以做出针对性的优化。   需要填写所处部门，需求类型（后台或活动），是否达到预期，维度包括成果、沟通、响应等。   最后还有两个可选项，就是填写意见或建议，以及最想表扬的同学及其理由。   若是正面反馈，那自然很好；若是负面反馈，那就要总结。   在实际执行后，发现大家很少会提意见，每次的分值也差不多。   但是每次点名表扬的都比较多，大家对我们组的工作都比较满意。 **3）北极星指标**   我们公司每个组都会有北极星指标（例如用户新增数、XX营收、主动聊天率等），了解各个组的指标变化其实就能了解公司业务的变化。   公司每个组长都会要求填写双月的 OKR，OKR 的内容其实也是围绕着北极星指标来的，阅读每周的备注，也能了解些业务变化。   如果有条件的话，那些细分下来支撑北极星指标的各类核心指标也可以去了解下。   以会员为例，包括日付费人数、日下单量、首次充值人数、连续包月续订人数、会员购买 UV 等。   在更好的理解业务后，并且有数据支撑，相信能更容易、更科学的找到真正需要优化的点，做到技术赋能业务增长。 ***** > 原文出处： [博客园-前端体验优化](https://www.cnblogs.com/strick/category/2360021.html) [知乎专栏-前端性能精进](https://www.zhihu.com/column/c_1610941255021780992) 已建立一个微信前端交流群，如要进群，请先加微信号freedom20180706或扫描下面的二维码，请求中需注明“看云加群”，在通过请求后就会把你拉进来。还搜集整理了一套[面试资料](https://github.com/pwstrick/daily)，欢迎阅读。  推荐一款前端监控脚本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不仅能监控前端的错误、通信、打印等行为，还能计算各类性能参数，包括 FMP、LCP、FP 等。