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
)来计算
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 服务器
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
、负载均衡
等优化措施
- 用户留存低:
提升应用的市场率,一个综合且漫长的过程,是运营、产品、技术等共同协作的目标。
利用监控结果,来调整新的策略,综合施策,来适应应用场景,不断留住用户
总结
整篇文章侧重于性能监控方面,关于用户行为监控可能更多的需要和产品经理探讨,根据监控数据改变业务策略,来不断提升用户的留存和转化。 性能监控,涉及的面比较广、链路比较长,针对前端开发要掌握常见的监控指标,理解监控的整个链路。