首发于前端监控
前端监控 - 首屏统计的前世今生

前端监控 - 首屏统计的前世今生

本文来自阿里云ARMS前端监控团队,转载请注明出处

前言

大家都知道,首屏性能对点击率、转换率等有很大影响,以下是我们统计的淘宝旺铺点击率和首屏时间的关系,随着首屏时间从1秒增大到8秒,点击率逐步从85%降低到了82%





可到底什么才是首屏呢?又是如何统计出来的?让我们一起来看看首屏统计的前世今生


首屏统计的前世今生


手动打点时期

回到那个刀耕火种的年代,那个时候要什么没什么,基本靠“自己动手,丰衣足食”。在页头和我们认定的首屏元素处分别通过new Date()打点,计算两者的差值作为首屏时间。再通过setTimeout(function,0)来标识首屏可交互时间

setTimeout(function(){ 
// new Date()
}, 0);


W3C标准化时期

随着前端的飞速发展,手工打点的模式早已满足不了需求了。为了帮助开发人员更好地衡量和改进web性能,W3C性能小组引入了 Navigation Timing API 帮我们自动,精准的实现了性能测试的打点问题


var perfData = window.performance.timing; 
var renderTime = perfData.domComplete - perfData.domLoading;


标准失效时期

在很长一段时间里,我们都享受着performance API带来的便利, 但随着SPA模式的盛行,我们再回过头来看看W3C标准是否足够了, 且看下面的案例,performance.timing得到的首屏值是779ms, 而通过截屏工具得到的值约为4400ms. 实际上SPA的盛行让W3C标准失去了原来的意义。





现阶段

针对这种情况Google lighthouse提出了FMP的概念,first meaning paint, 也就是主要内容可见时间,那什么是主要内容? 每个人得出的结论可能会不一样,先做一个猜想:主要内容 = 页面渲染过中元素增量最大的点。


先通过飞猪案例做一次验证, 渲染过程大体分为两步



统计整个渲染中的元素变化,在609毫秒的时候,增量最大,符合预期


再看看另外一个手淘的案例,渲染过程大体分为两步,相比飞猪多了一步占位屏。


![手淘案例](![IMAGE](quiver-image-url/6E04428ED5C14C7F9DB6AA0836C651C4.jpg =866x528)


再来看看元素的变化,这回增量最大的是第一屏,而认知上,我们认为第三屏才是主要内容,猜想不成立





那到底是什么原因导致我们的猜想不成立?

  • 首先很容易想到的是元素是否可见,元素如果是不可见的,那就算增加再多,对用户也是无感知的,一定不能认定为主要内容。
  • 其次是每个元素对页面的影响是否等效?从手淘的案例来看,占位屏的信息价值明显比不上第三屏的内容。因此,对不同的元素需要有不同的权重来衡量。阿里云前端监控是取元素到根节点的长度作为权重。 根据上面的修正因子。我们重新设计了一遍算法,如下图所示





分为三个步骤

  1. 侦听页面元素的变化
  2. 遍历每次新增的元素,并计算这些元素的得分总和
  3. 如果元素可见,得分为 1 * weight(权重), 如果元素不可见,得分为0


如果每次都去遍历新增元素并计算是否可见是非常消耗性能的。实际上采用的是深度优先算法,如果子元素可见,那父元素可见,不再计算。 同样的,如果最后一个元素可见,那前面的兄弟元素也可见。通过深度优先算法,性能有了大幅的提升。


再拿之前的手淘案例来验证一遍,经过改良之后,第三屏主要内容的得分是最高的,符合预期。






我们对主要的网站都做了一次验证,基本上能通过验证,但仍然没法做到100%准确。体验请点击


展望

展望未来,首屏统计又会朝着什么方向发展呢? 其实统计首屏时间本身就是浏览器的职责,交由浏览器来处理是最好的。 目前W3C关于首屏统计已经进入了提议阶段,坐等W3C再次标准化。可以在github上看到最新的进展, 详见w3c/paint-timing





本文来自阿里云ARMS前端监控团队,转载请注明出处

发布于 2018-09-19

文章被以下专栏收录