Web前端监控的方案

前端监控是一个非常重要的话题，对于业务的发展意义重大，就像遍布在城市各处的探头，实时监测整座城市的运行状况，保证系统的稳定、高效运行。

前端监控的意义

前端监控，对于业务和团队的重要性，不言而喻，是前端领域绕不开的一个话题。最大的意义是能了解系统的运行状态，哪些地方还有优化的空间，让App和网站运行的更流畅，从技术的角度为业务赋能，获取到更多的潜在用户。

著名的 2-5-8 原则

当用户能够在 2 秒以内得到响应时，会感觉系统的响应很快；
当用户在 2-5 秒之间得到响应时，会感觉系统的响应速度还可以；
当用户在 5-8 秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；
而当用户在超过 8 秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个 Web 站点，或者发起第二次请求。

监控的内容

主要包括用户行为、程序异常、运行性能这三方面的内容。

用户行为，用户在网站或App上浏览了哪些模块，热点区域有哪些，用户画像等数据
程序异常，系统运行过程中JS脚本报错、资源（图片、CSS等）加载异常信息
运行性能，侧重系统的性能指标，比如页面的白屏时间、秒开率，载入时长等

本文更侧重于介绍用户行为数据和运行指标的上报监控链路，程序异常的异常监控一般会采用业界的主流方案，比如sentry 这样的监控系统来辅助处理系统的错误异常。

监控的形式

监控的形式，主要分为两类：主动监控和被动监控。

被动监控，基于真实用户场景，通常经过页面埋点、数据上报、统计分析和生成报警等环节。
主动监控，基于仿真模拟环境，通过主动嗅探页面的运行状态达到实时监测的目的。

总体方案设计

一般监控系统，都是经过页面埋点，数据上报，后台存储，汇总统计，报警展示，优化整改等几个环节，每个环节都可以采用不同的方案来迎合业务的需求。

页面埋点，（前端埋点）设定好在哪些地方上报统计的数据，比如用户点击某个按钮时，上报相应的数据标识，又或者在页面初始化的过程中，
数据上报，将前端采集的到数据信息，发送给监控统计的后台接口
数据存储，监控数据存储的地方，根据数据量的大小选择不同的方案，如关系型数据库MySQL、Hadoop等
汇总统计，上报的监控数据，有很多无效的，需要清洗加工，按需统计汇总，方便展示
报警展示，一般需要搭建一个管理平台，设置监控指标的阈值参数，当触发时，通知给开发
优化整改，监控的最终目的让系统运行更优，根据监控结果制定系统的下一步优化方案

监控指标（范围）

在页面埋点时，选择哪些指标十分重要，需要和业务方统一好口径。一个完善的监控系统，监控的指标要全面、细粒度、易于量化等。

性能指标

常见的性能指标

FP 白屏（First Paint ）表示网页上的第一个像素点绘制的时间
FCP 首屏（first contentful paint ）首次内容绘制时间（首次绘制文本、图片（包含背景图）、非白色的canvas或SVG时才被算作FCP）
FMP 首次有意义的绘制（First Meaningful Paint ）首次有意义的内容绘制时间（网页上的主体区域展示出来的时间）
TTI （Time To Interactive）可交互时间，应用在视觉上都已渲染出了，完全可以响应用户的输入了。是衡量应用加载所需时间并能够快速响应用户交互的指标
TBT（total blocking time ）总阻塞时间，度量了FCP 和 TTI之间的总时间
CLS(Cumulative Layout Shift) 累计布局位移，发生的每个意外的布局移位的所有单独布局移位分数的总和，衡量页面的视觉稳定性的指标
FPS（Frames Per Second）每秒帧率，每秒钟画面更新次数，动画相关的指标，当FPS太低的时候，会感觉页面卡顿
DCL （DOMContentLoaded）HTML 文档被完全加载和解析完成之后，DOMContentLoaded 事件被触发，无需等待样式，图片和iframe的完成加载

以上的指标，可以借助浏览器给我们提供的performance API(window.performance)来计算

js 复制代码

const timing = performance.timing

// DNS 解析耗时
timing.domainLookupEnd - timing.domainLookupStart

// TCP 连接耗时
timing.connectEnd - timing.connectStart

// SSL 安全连接耗时
timing.connectEnd - timing.secureConnectionStart

// 网络请求耗时
timing.responseStart - timing.requestStart

// 数据传输耗时
timing.responseEnd - timing.responseStart

// DOM 解析耗时
timing.domInteractive - timing.responseEnd

// 资源加载耗时
timing.loadEventStart - timing.domContentLoadedEventEnd 

/* 关键性能指标 */

// 首包时间
timing.responseStart - timing.domainLookupStart

// 白屏时间
timing.responseStart - timing.navigationStart 

// 首次可交互时间
timing.domInteractive - timing.requestStart 

// HTML 加载完成时间， 即 DOM Ready 时间
timing.domContentLoadedEventEnd - timing.navigationStart

// 页面完全加载时间
timing.loadEventStart - timing.navigationStart

Google Web Vitals - 使用者体验量化

谷歌认为之前的标准太复杂，指标太多了。Google 于 2020 年 5 年 5 日提出了新的使用者体验量化方式，推出 Web Vitals 是简化这个学习的曲线，大家只要观注 Web Vitals 指标表现即可。加载性能LCP，交互性FID，视觉稳定性CLS。只需要做好这三个，网站的性能基本上就可以了。

LCP（Largest Contentful Paint ）最大内容绘制时间，主要内容对用户的可见时间。img图片，video元素的封面，通过url加载到的背景，文本节点等
FID （first Input Delay）首次输入延时，用户可在网页输入文字、点击按钮的时间
CLS （Cumulative Layout Shift）累计版面布局位移 (衡量网页元件视觉稳定性)

测量Web Vitals的工具有很多，比如Lighthouse，web-vitals，浏览器插件web vitals

用户指标

UV(用户访问数)、PV（页面被访问次数）、用户的留存率、转化率等等一般和业务耦合比较深，没有通用的范式。在采集时，结合业务需要，在特定的地方埋点，选择统计的表达式。

此时的UV = 3，PV = 10

秒开率应用在1秒（或1~2秒）内打开的用户占有率
用户留存在所有的访问用户中，有多少是DAU(日活跃用户)，月活，
用户转化在所有的到访用户群体中，有多少购买了产品或服务，转化成了业务收益

怎么留住老用户，吸引更多的新用户，将潜在的用户群体转化成业务的客户，是产品抉择过程要考虑的一个重要问题。这是通过监控系统，能拿到一手的数据，辅助产品的未来规划和决策。

前端埋点方案

页面买点主要有以下三种处理方式：

写死在业务代码，和业务逻辑耦合的比较深，也是最灵活的方式，维护比较麻烦，需要重新上线来调整
全量埋点，就是把各种监控相关的指标都上报去，想查啥数据都有，一般是提前引入相关监控脚本SDK
动态埋点，类似于WebPack开发构建中的热点更新技术（HMR）,先在业务项目引入基础的监控脚本，然后再监控管理平台配置要埋点的信息，再次发布增量监控脚本，自动下发到业务项目中

综合考虑，推荐采用动态埋点的方案，比较灵活，实现高效配置，不需要修改业务代码，只要在业务项目中引入基础SDK，实现无侵入式的前端监控。

上报逻辑

ajax、fetch上报，通过Ajax的方式往后台发送监控数据
image上报，使用一个 1像素的图片实现数据上报
jsonp上报，和image上报类似，支持跨域
sendBeacon 不占用网络请求资源，通常尝试在卸载（unload）文档之前向 Web 服务器发送数据

推荐使用最后一种方案navigator.sendBeacon(), 可用于通过 HTTP POST 将少量数据异步传输到 Web 服务器

js 复制代码

navigator.sendBeacon(url);
navigator.sendBeacon(url, data);
// 页面隐藏时，上报数据
document.addEventListener("visibilitychange", function logData() {
  if (document.visibilityState === "hidden") {
    navigator.sendBeacon("/log", analyticsData);
  }
});

当用户代理成功把数据加入传输队列时，sendBeacon() 方法将会返回 true，否则返回 false

使用 sendBeacon() 方法会使用户代理在有机会时异步地向服务器发送数据，同时不会延迟页面的卸载或影响下一导航的载入性能，这意味着：

数据发送是可靠的。
数据异步传输。
不影响下一导航的载入

监控数据的存储

Hadoop大数据平台，会将原始的监控数据存放到大数据平台，Hadoop 平台借助 Spark 做数据分析计算；借助 Hive 提供的接口，数据计算层使用 SQL 语句从 Hive 拉取计算后的数据到
MySQL关系型数据库，将加工统计后的数据，通过定时任务的方式导入到MySQL这样的关系型数据库中，便于在平台上展示监控结果
NoSQL存储，对于监控的参数配置、业务项目的管理、动态生成监控脚本可以存放在MongoDB中

管理平台展示

注册和管理业务项目

当业务项目，想要接入前端监控时，先在平台上注册一下，生成一个唯一的监控项目ID和监控SDK脚本。
在业务项目引入SDK脚本后，业务方的代码中就不会再出现监控相关的逻辑。
后续在监控平台配置业务项目的埋点信息即可，一般通过绑定DOM事件，来动态生成监控脚本，下发到监控页面中
业务项目上线后，如果要调整埋点配置，无需修改业务代码，在监控平台配置后，直接发布即可。
当后续有新版的监控脚本发布，SDK会自动拉取最新的监控配置，应用到业务终端页面

查看监控数据

根据监控上报的数据，可以在管理平台利用BFF层做数据的二次加工，生成各种维度的数据，丰富统计类型，更好地指导业务。

配置监控规则和阈值

在项目上线初期，数据波动比较大，需要在平台根据情况调整监控的埋点位置、阈值的参数、增加或删减一个埋点等

报警通知

原理：通过启动定时任务来读取配置表，根据不同的规则去读取es里面的数据（一分钟查询一次），如果有错误，则通知报警

报警通知的形式有：短信、邮件、平台消息、企业IM等，当某些监控指标出现异常时，需要通知到相关人员，及时处理。可以根据报警的级别，下发不同的通知形式。

严重且紧急的报警，一般通过短信、企业IM通知
正常的报警，一般通过邮件发送
无需特别处理的报警，在平台上展示消息即可

举个例子：性能标准是首屏时间 1.5s，秒开率 90%，如果超出 10%，平台上会标红展示，并会发企业微信报警通知；如果超过 20%，会发邮件报警；如果超出 30%，会发短信报警通知。

优化整改

性能不达标：

提升前端的性能，涉及的面比较广，比如提升首屏的秒开率。可以通过一下方式

懒加载只展示首屏可视区域内的元素，延迟加载首屏外的资源，尤其是图片、视频等
缓存，合理设置缓存策略，强缓存 + 协商缓存合理搭配，JS、CSS、图片等上传CDN，设置强缓存
开启 service-worker，保证离线下能正常展示，充分支持PWA
并行化，尽量支持HTTP2.0，开始数据传输的多通道模式，避免请求阻塞

除此之外，还有白屏优化、DNS优化、支持HTTPS、负载均衡等优化措施

用户留存低：

提升应用的市场率，一个综合且漫长的过程，是运营、产品、技术等共同协作的目标。

利用监控结果，来调整新的策略，综合施策，来适应应用场景，不断留住用户

总结

整篇文章侧重于性能监控方面，关于用户行为监控可能更多的需要和产品经理探讨，根据监控数据改变业务策略，来不断提升用户的留存和转化。性能监控，涉及的面比较广、链路比较长，针对前端开发要掌握常见的监控指标，理解监控的整个链路。