前端监控SDK开发 | 青训营笔记

皮卡丘丘呀
147 阅读6分钟

  这是我参与【第五届青训营】伴学笔记创作活动的第7天。

前端监控

什么是前端监控

  在浏览器里，从输入URL到页面展示发生了如下过程：   前端监控就是尽可能的采集这一过程以及后续用户交互中产出的性能指标与发生的异常事件并上报到平台完成消费。

为什么需要前端监控

  前端监控通过对页面数据的采集和上报，来帮助开发者更快速地对质量差的页面进行分析与归因。
  研究表明，性能不佳会对业务目标产生负面影响。例如，BBC发现他们的网站加载时间每增加一秒，他们就会失去10%的用户。

前端监控到底监控了什么

  1. 性能指标
  2. 异常事件
  3. 用户行为

常用性能指标

web性能标准的诞生

  早期网页是纯静态的，但随着Web 爆发式发展，页面交互越来越复杂。开发者开始思考如何提高 Web 性能、改善用户体验。
  因此，2010 年 8 月，W3C 成立了 Web 性能工作组，由来自 Google 和 Microsoft 的工程师担任主席，目标是制定衡量 Web 应用性能的方法和 API。
  随后， Web 性能工作组开始制定一系列 Web 性能标准，应用到桌面和移动浏览器以及其他环境中，帮助 Web 开发人员评估和理解应用的性能特征。

传统的性能指标

  传统的性能指标主要依赖 Navigation Timing 或者Navigation Timing 2，通过记录一个文档从发起请求到加载完毕的各阶段的性能耗时，以加载速度来衡量性能。

以用户为中心的性能指标

  • FP(First Paint):首次渲染的时间点。FP时间点之前，用户看到的都是没有任何内容的白色屏幕。
  • FCP(First Contentful Paint):首次有内容渲染的时间点。
  • FMP(First Meaningful Paint) :首次绘制有意义内容的时间点。
  • TTI(Time to Interactive):测量页面从开始加载到主要子资源完成渲染，并能够快速、可靠地响应用户输入所所需的时间。
      TTI反映页面可用性的重要指标。TTI值越小，代表用户可以更早地操作页面，用户体验就更好。
  • SI(Speed Index)：衡量页面可视区域加载速度，帮助检测页面的加载体验差异
  • FID(First Input Delay):测量从用户第一次与页面交互(比如当他们单击链接、点按按钮等等)直到浏览器对交互作出响应，实际能够开始处理事件时处理程序所经过的时间


为衡量用户体验过程的性能指标又增加以下性能指标：

  • LCP（Largest Contentful Paint）：最大的内容在可视区域内变得可见的时间点
  • TBT (Total Blocking Time):量化主线程在空闲之前的繁忙程度，有助于理解在加载期间，页面无法响应用户输入的时间有多久。
  • CLS (Cumulative Layout Shift):量化了在页面加载期间，视口中元素的移动程度。（可能造成误触）

前端常见异常

静态资源错误

  • 静态资源:加载页面所需的 html、css 和 js 等文件，以及其他各类多媒体文件，如图片、音频和视频等。
  • 静态资源错误:在拉取和加载静态资源的过程中发生了预期之外的错误，如网络异常等，导致静态资源无法正常渲染到页面上。

请求异常

  请求异常 = 请求响应状态码 >= 400
对于通过异步请求拉取的静态资源错误也可选择归纳到请求异常

  • 状态码0： 请求成功率 = 请求成功数 /（请求成功数+请求失败数）

JS错误

  在页面运行时发生的JS错误会严重影响页面的正常渲染与交互，是前端监控的重点。

白屏异常

  前面几类异常都可以通过浏览器提供的标准化方法来监听到，而白屏异常没有标准化的监听方法，所以更考验前端监控开发者的功底。
通常我们可以通过判断 DOM 树的结构来来粗略的判断白屏是否发生。
  监听到白屏发生后，我们还需要对白屏的发生进行归因。通常导致白屏发生的原因可能有如下几点:

  1. 发生 Js 错误导致关键资源渲染失败。
  2. 请求异常或静态资源加载失败。
  3. 长时间的 Js 线程繁忙阻塞渲染任务。

监控前端性能与异常

性能指标监控

  利用Performance和PerformanceObserver可以监控到一些标准渲染性能数据。
  Performance：developer.mozilla.org/zh-CN/docs/…
  PerformanceObserver：developer.mozilla.org/zh-CN/docs/…

JS错误监控

  利用window.addEventListener的error和unhandledrejection可以监控到全局的JS错误。
  addEventListener：developer.mozilla.org/zh-CN/docs/…
  error：developer.mozilla.org/en-US/docs/…
  unhandledrejection：developer.mozilla.org/zh-CN/docs/…

静态资源错误监控

  利用window.addEventListener的error事件可以监控到静态资源错误，注意要和js error进行区分。

请求异常监控

  通过hook xhr和fetch对象来监听请求时发生的错误。
  hook xhr：developer.mozilla.org/zh-CN/docs/…
  fetch：developer.mozilla.org/zh-CN/docs/…

封装一个通用的sdk

前端监控流程概述

  sdk主要完成前两步，后两步需要后端服务和平台的支持，其中前面的章节已经完成了数据采集以及简单的数据组装。

数据上报

  封装一个用于给监控器上报已收集数据的上报函数

按需加载监控能力

  下面我们需要将之前实现的监控器按需加载到sdk中，从而封装成一个完整的sdk

课后探索：让你的SDK更健壮

更多性能指标计算算法

关注请求性能

  请求异常除了请求错误外，我们还关注慢请求。你可以参考Performance Resource Timing来获取请求各阶段耗时，找出所有慢请求。
  Performance Resource Timing：developer.mozilla.org/zh-CN/docs/…

更安全和稳定的Hook函数

  在实现请求错误监控时，我们实现了一个很简易的 hook 函数，这个 hook 函数缺少了很关键的 unhook 能力，即将被 hook 的函数还原的能力。你能补全这一能力并写出更安全和稳定的 hook 函数吗？

用户行为监控

  由于篇幅限制，我们在本课程中没有介绍用户行为监控，这不代表它不是前端监控的关键一环，你可以尝试补全这一监控能力吗？

数据存储与消费

  sdk 提供了前面两个环节的能力，而后两个环节需要同时依赖前端和后端的能力来共同完成，你可以拉上其他同学们补全每一个环节吗？

avatar
文章
阅读
粉丝