回旋镖信标中的数据不一致
Data in boomerang beacons is inconsistent
我正在收集一些回旋镖数据,但是返回的帧速率数据对我来说没有意义。
我的两个主要问题是
- 为什么帧率时间线数据不匹配
- 为什么TTI这么高
首先我会给出我看到的完整信标
c.e: "kb8jhepo"
c.f: 61
c.f.d: 524
c.f.m: 2
c.f.s: "kb8jhge3"
c.t.fps: "0*5*62"
c.tti: 2075
c.tti.m: "lt"
c.tti.vr: 948
if: ""
n: 1
nt_con_end: 1591744341954
nt_con_st: 1591744341954
nt_dec_size: 129958
nt_dns_end: 1591744341954
nt_dns_st: 1591744341954
nt_domcomp: 1591744343076
nt_domcontloaded_end: 1591744342895
nt_domcontloaded_st: 1591744342814
nt_domint: 1591744342577
nt_domloading: 1591744342159
nt_enc_size: 41324
nt_fet_st: 1591744341954
nt_first_paint: 1591744342325
nt_load_end: 1591744343120
nt_load_st: 1591744343082
nt_nav_st: 1591744341948
nt_nav_type: 1
nt_protocol: "h2"
nt_red_cnt: 0
nt_req_st: 1591744341964
nt_res_end: 1591744342373
nt_res_st: 1591744342144
nt_ssl_st: 1591744341954
nt_trn_size: 42860
nt_unload_end: 1591744342154
nt_unload_st: 1591744342154
pid: "a6ilbd4j"
pt.fcp: 377
pt.fp: 377
rt.si: "kd7mvv6mutl-NaN"
rt.sl: 0
rt.ss: undefined
ua.plt: "MacIntel"
ua.vnd: "Google Inc."
v: "1.0.0"
vis.st: "visible"
在 doc 上总结了计算 TTI 的算法
Putting these two timers together, here's how we measure Visually Ready and Time to Interactive:
1. Determine the highest Visually Ready timestamp (VRTS):
* Largest Contentful Paint (if available)
* First Contentful Paint (if available)
* First Paint (if available)
* domContentLoadedEventEnd
* Hero Images are loaded (if configured)
* Framework Ready (if configured)
2. After VRTS, calculate Time to Interactive by finding the first period of 500ms where all of the following are true:
* There were no Long Tasks
* The FPS was always above 20 (if available)
* Page Busy was less than 10% (if the above aren't available)
帧率
c.f
等于 61,根据 docs 是持续时间基础上的平均帧速率。然而,当我获取 c.t.fps
中给出的时间线数据时,我得到一个 "0*5*62"
的压缩值,当我根据他们的算法解压缩时,我得到 [6, 6, 6, 6, 6, 2]
,这显然不会平均到 61.
帧速率持续时间 c.f.d
是 524 毫秒,这就是为什么我有那么多数据点但我看不到平均值如何与时间线匹配。
奖金问题:有人可以深入了解帧速率何时开始和停止测量吗?
TTI
TTI 使 IMO 更加混乱。我从信标 2075 获得的值和使用的方法是 lt
(或 LongTask)。然而,其他数据点不支持作为 TTI 值。视觉准备时间要低得多,为 948,信标中没有长任务数据,因此推测这不是计算 TTI 的因素。
剩下的最后一件事是帧速率,如上所述,我似乎并不理解。我不清楚帧速率何时(或是否曾经)满足这些要求
我最终能够通过回旋镖代码自行解决这个问题...
[6, 6, 6, 6, 6, 2]
的数组更像是每 100 毫秒的帧数而不是 fps。 TTI真的是在这个block.
上计算的
if (idleIntervals >= TIME_TO_INTERACTIVE_IDLE_INTERVALS) {
tti = startTime + ((j - TIME_TO_INTERACTIVE_IDLE_INTERVALS) * COLLECTION_INTERVAL);
// ensure we don't set TTI before TTVR
tti = Math.max(tti, visuallyReady);
break;
}
真正的意思是连续idleIntervals
的数量需要>=5(TIME_TO_INTERACTIVE_IDLE_INTERVALS
)。
在我上面的例子中,我们没有很长的任务数据,并且视觉准备时间发生在 tti 之前,所以给我们留下了每秒的帧速率。如上所述,我错误地解释了这些比率
当它使用 fps 来确定一个间隔是否空闲时,它使用以下代码 block
if (data.fps && (!data.fps[j] || data.fps[j] < TIME_TO_INTERACTIVE_MIN_FPS_PER_INTERVAL)) {
// No FPS or less than 20 FPS during this interval
idleIntervals = 0;
continue;
}
TIME_TO_INTERACTIVE_MIN_FPS_PER_INTERVAL
其实就是2
,就是在这个line
上计算的
/**
* For Time to Interactive, minimum FPS per COLLECTION_INTERVAL.
*/
var TIME_TO_INTERACTIVE_MIN_FPS_PER_INTERVAL =
TIME_TO_INTERACTIVE_MIN_FPS / (1000 / COLLECTION_INTERVAL);
因此每秒帧速率是 tti 值的限制因素。测量的前 5 个帧速率值被认为对 tti “良好”。但它仍然比ttvr高很多的原因是帧速率直到后来才开始测量。
开始测量帧速率的时间由信标值c.f.s
(base36 编码的纪元时间)给出。回旋镖测量任何东西的时间由 c.e
给出。如果您通过 wiki 中的信标示例了解这两者的区别,您将得到 boomerang
返回的 tti 值
我正在收集一些回旋镖数据,但是返回的帧速率数据对我来说没有意义。
我的两个主要问题是
- 为什么帧率时间线数据不匹配
- 为什么TTI这么高
首先我会给出我看到的完整信标
c.e: "kb8jhepo"
c.f: 61
c.f.d: 524
c.f.m: 2
c.f.s: "kb8jhge3"
c.t.fps: "0*5*62"
c.tti: 2075
c.tti.m: "lt"
c.tti.vr: 948
if: ""
n: 1
nt_con_end: 1591744341954
nt_con_st: 1591744341954
nt_dec_size: 129958
nt_dns_end: 1591744341954
nt_dns_st: 1591744341954
nt_domcomp: 1591744343076
nt_domcontloaded_end: 1591744342895
nt_domcontloaded_st: 1591744342814
nt_domint: 1591744342577
nt_domloading: 1591744342159
nt_enc_size: 41324
nt_fet_st: 1591744341954
nt_first_paint: 1591744342325
nt_load_end: 1591744343120
nt_load_st: 1591744343082
nt_nav_st: 1591744341948
nt_nav_type: 1
nt_protocol: "h2"
nt_red_cnt: 0
nt_req_st: 1591744341964
nt_res_end: 1591744342373
nt_res_st: 1591744342144
nt_ssl_st: 1591744341954
nt_trn_size: 42860
nt_unload_end: 1591744342154
nt_unload_st: 1591744342154
pid: "a6ilbd4j"
pt.fcp: 377
pt.fp: 377
rt.si: "kd7mvv6mutl-NaN"
rt.sl: 0
rt.ss: undefined
ua.plt: "MacIntel"
ua.vnd: "Google Inc."
v: "1.0.0"
vis.st: "visible"
在 doc 上总结了计算 TTI 的算法
Putting these two timers together, here's how we measure Visually Ready and Time to Interactive:
1. Determine the highest Visually Ready timestamp (VRTS):
* Largest Contentful Paint (if available)
* First Contentful Paint (if available)
* First Paint (if available)
* domContentLoadedEventEnd
* Hero Images are loaded (if configured)
* Framework Ready (if configured)
2. After VRTS, calculate Time to Interactive by finding the first period of 500ms where all of the following are true:
* There were no Long Tasks
* The FPS was always above 20 (if available)
* Page Busy was less than 10% (if the above aren't available)
帧率
c.f
等于 61,根据 docs 是持续时间基础上的平均帧速率。然而,当我获取 c.t.fps
中给出的时间线数据时,我得到一个 "0*5*62"
的压缩值,当我根据他们的算法解压缩时,我得到 [6, 6, 6, 6, 6, 2]
,这显然不会平均到 61.
帧速率持续时间 c.f.d
是 524 毫秒,这就是为什么我有那么多数据点但我看不到平均值如何与时间线匹配。
奖金问题:有人可以深入了解帧速率何时开始和停止测量吗?
TTI
TTI 使 IMO 更加混乱。我从信标 2075 获得的值和使用的方法是 lt
(或 LongTask)。然而,其他数据点不支持作为 TTI 值。视觉准备时间要低得多,为 948,信标中没有长任务数据,因此推测这不是计算 TTI 的因素。
剩下的最后一件事是帧速率,如上所述,我似乎并不理解。我不清楚帧速率何时(或是否曾经)满足这些要求
我最终能够通过回旋镖代码自行解决这个问题...
[6, 6, 6, 6, 6, 2]
的数组更像是每 100 毫秒的帧数而不是 fps。 TTI真的是在这个block.
if (idleIntervals >= TIME_TO_INTERACTIVE_IDLE_INTERVALS) {
tti = startTime + ((j - TIME_TO_INTERACTIVE_IDLE_INTERVALS) * COLLECTION_INTERVAL);
// ensure we don't set TTI before TTVR
tti = Math.max(tti, visuallyReady);
break;
}
真正的意思是连续idleIntervals
的数量需要>=5(TIME_TO_INTERACTIVE_IDLE_INTERVALS
)。
在我上面的例子中,我们没有很长的任务数据,并且视觉准备时间发生在 tti 之前,所以给我们留下了每秒的帧速率。如上所述,我错误地解释了这些比率
当它使用 fps 来确定一个间隔是否空闲时,它使用以下代码 block
if (data.fps && (!data.fps[j] || data.fps[j] < TIME_TO_INTERACTIVE_MIN_FPS_PER_INTERVAL)) {
// No FPS or less than 20 FPS during this interval
idleIntervals = 0;
continue;
}
TIME_TO_INTERACTIVE_MIN_FPS_PER_INTERVAL
其实就是2
,就是在这个line
/**
* For Time to Interactive, minimum FPS per COLLECTION_INTERVAL.
*/
var TIME_TO_INTERACTIVE_MIN_FPS_PER_INTERVAL =
TIME_TO_INTERACTIVE_MIN_FPS / (1000 / COLLECTION_INTERVAL);
因此每秒帧速率是 tti 值的限制因素。测量的前 5 个帧速率值被认为对 tti “良好”。但它仍然比ttvr高很多的原因是帧速率直到后来才开始测量。
开始测量帧速率的时间由信标值c.f.s
(base36 编码的纪元时间)给出。回旋镖测量任何东西的时间由 c.e
给出。如果您通过 wiki 中的信标示例了解这两者的区别,您将得到 boomerang