共计 2843 个字符，预计需要花费 8 分钟才能阅读完成。
什么是前端监控？
它指的是通过肯定的伎俩来获取用户行为以及跟踪产品在用户端的应用状况，并以监控数据为根底，为产品优化指明方向，为用户提供更加准确、欠缺的服务。
如果这篇文章有帮忙到你，❤️关注 + 点赞❤️激励一下作者，文章公众号首发，关注 前端南玖 第一工夫获取最新的文章～
前端监控
一般来讲一个成熟的产品，经营与产品团队须要关注用户在产品内的行为记录，通过用户的行为记录来优化产品，研发与测试团队则须要关注产品的性能以及异样，确保产品的性能体验以及平安迭代。
所以前端监控个别也分为三大类：
数据监控（监控用户行为）
- PV/UV: PV(page view)：即页面浏览量或点击量；UV：指拜访某个站点或点击某条新闻的不同 IP 地址的人数
- 用户在每一个页面的停留时间
- 用户通过什么入口来拜访该网页
- 用户在相应的页面中触发的行为，等 …
统计这些数据是有意义的，比方咱们晓得了用户起源的渠道，能够促成产品的推广，晓得用户在每一个页面停留的工夫，能够针对停留较长的页面，减少广告推送等等。
性能监控（监控页面性能）
- 不同用户，不同机型和不同零碎下的首屏加载工夫
- 白屏工夫
- http 等申请的响应工夫
- 动态资源整体下载工夫
- 页面渲染工夫
- 页面交互动画实现工夫，等 …
这些性能监控的后果，能够展现前端性能的好坏，依据性能监测的后果能够进一步的去优化前端性能，尽可能的进步用户体验。
异样监控（监控产品、零碎异样）
及时的上报异常情况，能够防止线上故障的发上。尽管大部分异样能够通过 try catch 的形式捕捉，然而比方内存透露以及其余偶现的异样难以捕捉。常见的须要监控的异样包含：
- Javascript 的异样监控
- 款式失落的异样监控
埋点上报
OK，下面咱们说到了前端监控的三个分类，理解了一个产品须要监控哪些内容以及为什么须要监控这些内容，那么咱们应该怎么实现前端监控呢？
实现前端监控，第一步必定是将咱们要监控的事项（数据）给收集起来，再提交给后盾进行入库，最初再给数据分析组进行数据分析，最初解决好的数据再同步给经营或者是产品。数据收集的丰富性和准确性会间接影响到咱们做前端监控的品质，因为咱们会以此为根底，为产品的将来倒退指引方向。
当初常见的埋点上报办法有三种：手动埋点、可视化埋点、无埋点
手动埋点
手动埋点，也叫代码埋点，即纯手动写代码，调用埋点 SDK 的函数，在须要埋点的业务逻辑功能位置调用接口，上报埋点数据，像 [友盟]、[百度统计] 等第三方数据统计服务商大都采纳这种计划。手动埋点让使用者能够不便地设置自定义属性、自定义事件；所以当你须要深刻下钻，并精细化自定义剖析时，比拟适宜应用手动埋点。
手动埋点的缺点就是，我的项目工程量大，须要埋点的地位太多，而且须要产品开发经营之间互相重复沟通，容易呈现手动过错，如果谬误，从新埋点的老本也很高。
可视化埋点
通过可视化交互的伎俩，代替上述的代码埋点。将业务代码和埋点代码拆散，提供一个可视化交互的页面，输出为业务代码，通过这个可视化零碎，能够在业务代码中自定义的减少埋点事件等等，最初输入的代码耦合了业务代码和埋点代码。
可视化埋点的缺点就是能够埋点的控件无限，不能手动定制。
无埋点
无埋点则是前端主动采集全副事件，上报埋点数据，由后端来过滤和计算出有用的数据。长处是前端只有一次加载埋点脚本，毛病是流量和采集的数据过于宏大，服务器性能压力山大。
为什么都用 GIF 来做埋点？
发现过程
首先说一下我是怎么发现的，前一段时间，产品提了个需要，说咱们当初的书籍曝光上报标准并不是他们想要的数据，并且当前所有页面的书籍上报都对立成最新标准。
曝光标准：
- 书籍呈现在可视区并停留 1 秒，算作无效曝光
- 书籍不能反复曝光，如果它始终在可视区滚动时只能上报一次
- 当它移出可视区后再回到可视区，再按第一点进行曝光
OK，既然要所有页面对立，那就只能封装成通用库来应用了，这里实现逻辑就不贴了，想看的私聊我发你，次要的难点就是停留时长计算，以及曝光标记。
const exposeReportClass = new exposeReport({
scrollDom: "", // 滚动容器，倡议指定一个滚动容器，不传默认为 window
watchDom: ".bookitem", // 监听的 dom, 倡议应用 class 类，标签也反对
time: 1000 // 停留无效时长 ms
});
// 提供两个上报办法
exposeReportClass.didReport(()=>{
// 手动上报
//callback
})
exposeReportClass.scrollReport(()=>{
// 滚动动上报
//callback
})
// 具体业务逻辑之须要放在对应的 callback 外面，而上报逻辑开发者无需思考，因为我底层曾经对立解决好了。
而后我再测试的时候就发现，上报发的申请竟然是通过图片发动的，并不是咱们认为的接口上报。
而后我去查了下材料，发现很多大厂的上报都是这么干的！
应用 GIF 上报的起因
向服务器端上报数据，能够通过申请接口，申请一般文件，或者申请图片资源的形式进行。只有能上报数据，无论是申请 GIF 文件还是申请 js 文件或者是调用页面接口，服务器端其实并不关怀具体的上报形式。那为什么所有零碎都对立应用了申请 GIF 图片的形式上报数据呢？
- 避免跨域
一般而言，打点域名都不是以后域名，所以所有的接口申请都会形成跨域。而跨域申请很容易呈现因为配置不当被浏览器拦挡并报错，这是不能承受的。但图片的 src 属性并不会跨域，并且同样能够发动申请。（排除接口上报）
- 避免阻塞页面加载，影响用户体验
通常，创立资源节点后只有将对象注入到浏览器 DOM 树后，浏览器才会理论发送资源申请。重复操作 DOM 不仅会引发性能问题，而且载入 js/css 资源还会阻塞页面渲染，影响用户体验。
然而图片申请例外。结构图片打点不仅不必插入 DOM，只有在 js 中 new 出 Image 对象就能发动申请，而且还没有阻塞问题，在没有 js 的浏览器环境中也能通过 img 标签失常打点，这是其余类型的资源申请所做不到的。（排除文件形式）
- 相比 PNG/JPG，GIF 的体积最小
最小的 BMP 文件须要 74 个字节，PNG 须要 67 个字节，而非法的 GIF，只须要 43 个字节。
同样的响应，GIF 能够比 BMP 节约 41% 的流量，比 PNG 节约 35% 的流量。
并且大多采纳的是 1 * 1 像素的通明 GIF 来上报
1×1 像素是最小的非法图片。而且，因为是通过图片打点，所以图片最好是通明的，这样一来不会影响页面自身展现成果，二者示意图片通明只有应用一个二进制位标记图片是通明色即可，不必存储色调空间数据，能够节约体积。
举荐浏览
- 介绍回流与重绘（Reflow & Repaint），以及如何进行优化?
- Promise、Generator、Async 有什么区别？
- 【Vue 源码学习】依赖收集
- 【Vue 源码学习】响应式原理探秘
- JS 定时器执行不牢靠的起因及解决方案
- 从如何应用到如何实现一个 Promise
- 超具体解说页面加载过程
原文首发地址点这里，欢送大家关注公众号 「前端南玖」
我是南玖，咱们下期见！！！