【Chrome火焰图性能分析】

遇到的问题

背景是我们组项目接入了sentry用来监控首屏打开的时间。但是在统计数据和打开速度上存在不一致的情况，sentry监控首屏时间会在一到两秒，但是实际打开页面到最后一个接口调用从视觉感受上不会超过一秒。

分析过程

下面是sentry监控的时间图

可以看出在url/report/list 前后均有一大段的留白部分，然后通过浏览器控制台性能监控url/report/list后面的火焰图

可以看到这个接口调用之后有很长一段时间都在执行js脚本

查看里面自身耗时最长的js调用是querySelectorAll方法。ok这就引出了我们的另一个sdk项目，数据加解密。
因为领导需要，要对页面上展示的一些敏感信息进行加解密处理，也就是过来展示在页面上的不能是明文。所以最初设计的思路是前端设计一个sdk，通过拦截请求携带特殊的请求头信息来通知网关进行加密处理，前端则通过 MutationObserver 开启对document及其后代变化的观察，以判断满足 textNode.nodeValue 命中某个正则之后进行可解密dom的替换操作。但是因为接口的复用，有些数据在下拉枚举中或者输入框的回显中也被替换成加解密之后的dom了，因此需要对这部分做自动解密的操作，所以引出了这个现状的罪魁祸首

这里的逻辑是通过判定当前帧内所剩余的可使用的空闲时间，然后触发空闲回调逻辑，然后查询页面所有的对应标签选择器的dom然后进行自动解密的操作，从目前的现状看就是sentry把后续的空闲回调时间也记录到主线程阻塞时间中了。目前把开发环境的加密逻辑下掉可以看出时间是正常的了。

改进建议

后续的改进想法，第一个就是将这部分自动解密的逻辑改到观察者回调逻辑当中，或者将这里空闲回调的触发变成可控的而不是空闲时一直回调的情况。