Continuity Visually Ready (c.tti.vr) gradually increased in Chromium 105 and 106 about boomerang

[querymetrics]

Hi @Quadiago , thanks for reaching out.

I asked @tvereecke to look at his site's data. He does not see an increase in c.tti, but does see an increase in c.tti.vr from 105 to 106.

Do you have the PaintTiming plugin?
If so, c.tti.vr is calculated from max(LCP || FCP || FP, domContentLoadedEnd)
Do you see increases in pt.fp, pt.lcp, pt.fcp or nt_domcontentloaded_end?

[querymetrics]

@tvereecke did some more analysis and found that FCP, LCP and DOM content loaded didn't change in his site's data from 105 to 106

[Quadiago]

Hi @querymetrics ! Thanks for responding.

Yes, we also could not find changes to FCP or LCP. It only affected c.tti.vr. Our pages are mostly rendered server-side, so c.tti is equal to c.tti.vr 80% of the time. We tracked it down to the bug linked above which the Chromium devs have recently started rolling out in 108. The data is limited, but we can already see a significant drop in TTI in Chrome 108.0.0 thanks to the fix being rolled out.

In Boomerang terms, the problem is this line:

https://github.com/akamai/boomerang/blob/master/plugins/continuity.js#L1524

If this were to be refactored to use performance.timing.navigationStart instead of performance.timeOrigin, we would have not seen the bug in this particular fashion. Either way, this isn't a Boomerang bug, but a Chromium one, so I'm happy to close this.