Closed Quadiago closed 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
?
@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
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.
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.