Web性能测量中的"交互时间"度量标准

Question

显然,"交互时间"是在测量网页感知速度时使用的新指标.我有兴趣了解它实际上是什么.

这个术语显然是由Radware创造的,并且正在被推动为最有意义的性能测量(与Time to First/Last Byte,Time to Render等相比).

它被描述为:

页面显示其主要交互式(想想可点击)内容的点,而不是整页加载.

这对我来说似乎很主观; 例如,网页的"主要互动内容"是什么？

有报道引用测量结果,因此有些测量结果如何,而且必须自动化,因为结果集非常大(测试了约500个站点).

除了以上引用之外,我找不到有关如何衡量这一点的更多信息.

由于谷歌更加重视折叠内容(或可见内容),我想知道这个指标是否实际上更像是"第一次有意义渲染的时间",即它是当前页面目标的上下文.例如,在电子商务网站的产品页面上,这可能是主要图像,以及添加到购物篮链接.

我很想理解这个指标,对我而言,它似乎是最有用的指标.因此,我的问题是,是否有人在测量这一点,如果是这样,他们是如何做到的？

Answer 1

你回答了自己的问题,对你当前的项目来说是主观的,并且与你有关.

如果我在没有任何复杂资源的情况下测试只有HTML的网站怎么办？没有必要在那里测量TTI.另一方面,让我们看看这个演示网站.

这里有更大的图片.

蓝线标记"COMContentLoaded"事件(加载主文档并解析标记),红线表示加载所有页面资源的加载事件.TTI线将介于两条线之间,根据交互资源加载事件的一些必要条件,每条线的定义不同.

例如,假设演示站点上的图片对于网站的核心功能不是必不可少的.虽然主站点在0.8秒内加载,但是3张大图片需要额外加载36秒,因此在这种情况下使用总体响应时间作为KPI将产生约36秒的响应时间,而如果您定义TTI除了那些大的,非必要的资源,你最终得到<1s的响应时间.

我很想理解这个指标,对我而言,它似乎是最有用的指标.

绝对有用,但正如你在问题中所说,这是项目的具体内容.您不会在一个简单的,相对静态的Web应用程序上测量TTI,您可能会测量总体响应时间.我总是为当前项目定义"定制"的KPI,而不是尝试使用常用指标,并在项目中"强制使用".

因此,我的问题是,是否有人在测量这一点,如果是这样,他们是如何做到的？

以前绝对使用它,您应该确定您的站点的基本资源,并在加载最后一个这些资源时,这就是您的TTI.这可能是一个javascript文件,一个CSS等...

Answer 2

网站变得越来越复杂。尽管它们可能并不总是包含更多内容，但它们仍然有更多资源需要加载，因为从技术角度来看，用户交互/用户体验更加复杂。Ajax帮助我们分别加载不同的部分。因此，我们加载的不是一页，而是几件小事。对于每个部件，我们都可以测量负载性能。但网站上的某些部分可能比其他部分更重要。“主要交互内容”是您的视图中使用户能够做他想做的事情的部分，例如购买火车票。如果屏幕左侧的某些广告或特殊动画尚未加载，这并不妨碍用户开始购买门票。但当然，“主要交互内容”作为一个术语是相当模糊的，您必须根据您的特定应用程序来定义它。当某些部分仍在加载时，普通用户可以并且将开始与网站进行交互。

这就是我理解这个概念的方式，我在这里看到了与“首次有意义渲染的时间”的区别：您的电子商务页面上可能会渲染一个购物篮，但 GUI 尚未响应。所以你看到了一些有意义的东西，但交互性还不存在。因此 TTI >= TtFMR。

衡量 TTI 需要您定义交互性所需的元素，这不仅取决于站点的功能，还取决于站点的工作方式。所以这很大程度上取决于您的实施/技术。