• 知乎 逐帧分析youtube 看到Google如何优化
• B站 GMTC B 站的视频体验进化之路 可搜到ppt
• 公众号 GMTC 蚂蚁金服如何把前端性能监控做到极致?
  • 对应的视频 腾讯视频

蚂蚁金服如何把前端性能监控做到极致?

细节不先展开。

监控两种，一种是实验室，也就是合成监控Synthetic Monitoring SYN，另一种真实用户监控Real User Monitoring RUM

合成监控。

yslow webpagetest 以Lighthouse为准就好了。

真实用户监控。也就是上监控系统了。

w3c 提供了更全面的性能矩阵，比单一的 performance.timing 更强大。，从原来的 navigation.timing leve1 编程了下图

哦，原来如此。

采集性能数据时先抹平 Navigation Timing spec 差异，优先使用 PerformanceTimeline API(在复杂场景，亦可考虑优先使用 PerformanceObserver)。

性能指标。单页面情况下，html很小，fp和fcp差异很小，70%情况下小于100ms，都是js里提供的。

fmp缺点

performance.timing形成的模型。

start render 一帧一帧拍摄，观察页面发生变化，这个是用户可观渲染得到的，之前的fp是js运行得到的

DNS查询完马上就建立tcp连接了吗？tcp连接完马上去发送请求了吗？不一定的，这就是 stalled 停滞等待。

在devtools中可以看到，其实这个 stalled时间非常常见。

DNS每次都会查询吗？一般不会，一般会缓存，导致第二次访问dns查询时间0

Chrome68开始，tab不可见的资源会受到限制。也就是隐藏打开一页页面，很多性能指标不能正常打开。可以测试一下。

二次打开有缓存、还要serviceWorker

数据如何撒谎？同一个页面，不同的打开方式不同。这里讲到了百分比

95% - 把所有的页面加载时长，从小到大排列，去95%的结果。这意味着95%的人访问页面最多是这个结果

如果是10% 就是忽略掉极端情况，这个数据会更好看。

所以，如果对性能要求越高，百分比数字越大。

比如我们要承诺 99% 的用户都要小于 5 秒，我们看页面加载时长时候就应该看 99 分位数。如果我们现在精力不够，我们只能承诺 50% 的人页面加载时长小于 5 秒，实际上 50 分位数，就是中位数，就是 50% 的访问能够不小于这个时间打开这个页面。