search

akamai / boomerang

End user oriented web performance testing and beaconing
http://akamai.github.io/boomerang/
Other
1.86k stars 292 forks source link

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

Closed Quadiago closed 1 year ago

Quadiago commented 1 year ago

Hi all

I realize that the title of this issue makes it sound like I should be raising this against Chromium support, but I was hoping for some advice from the Boomerang community to start. We've started noticing an increase in c.tti (Boomerang TTI) on our pages which we've traced (is correlated) with a similar increase in c.tti.vr, which I believe is thanks to a change in performance.timeOrigin. I had thought initially it was thanks to changes to LCP, but my data does not back this up.

The only problem is, the changes made in Chromium to performance.timeOrigin should not have the effect we're seeing, so I'm hoping someone else has been looking at similar things and has some advice.

querymetrics commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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.