Closed sukratkashyap closed 3 years ago
@sukratkashyap this is a really great explanation and idea. Thank you for putting this together.
So if I'm understanding correctly, one of the major changes here is it makes it so idleIntervals
isn't needed to be re-calculated every time as we keep track of the bucketsVisited
to kind-of restart the calculation where we left off.
Have you thought about what a test might look like for this? It would be a little complex (and might have a few phases), but I think we could do it with a combination of some of the existing continuity tests plus waiting a bit after onload for the TTI to actually happen.
I don't see any other major concerns with the code. If you have time to build tests for this, that would be great, otherwise we can try to tackle them soon.
@sukratkashyap Thank you again for this PR. I've merged these changes and a few others suggested in https://github.com/akamai/boomerang/issues/315, into a new PR https://github.com/akamai/boomerang/pull/326, and have refactored things a bit so it can be unit-test covered.
I'm going to close out this PR, but I've noted your contributions in the other PR.
Thank you!
Hi Team,
Related partially on: https://github.com/akamai/boomerang/issues/248 https://github.com/akamai/boomerang/issues/245
What we want
We want
c.tti
to be calculated accurately on the page load beacon (spa_hard or undefined initiators).Cases it fails:
Unpredictable cases:
Predictable cases: According to our code, the assumption of the value of
c.tti
is:VisuallyReady
<c.tti
< (page_ready
+waitAfterOnLoad
)We try to calculate
c.tti
afterpage_ready
is fired and forwaitAfterOnLoad
ms. After which we send page load beacon withoutc.tti
. (Since our assumption equation didn't work for some users)Now, If
afterOnLoad=true
c.tti
is possible to be attached to any type of beacon, especially when it fails atpage_load
. But then thec.tti
values reported are very high and very unreliable. I know it's anyways not a good idea to trust them. But this PR tries to somewhat rectify that issue.Scenario
c.tti
failed to be calculatedc.tti
Timeline
class in Continuity flushes its data.c.tti
is calculated before every beacon being sent (but never has good enough data (for seeing 500ms CPU idle) because the real data gets flushed whenever a beacon is sent)!data.fps[j]
makes the function feel that the page was busy until the time we last started capturing the data. (which is when the User went to play COD mobile)c.tti
will be reported as the last time we started capturing the data. (and it will be a very large value, because of the time he spent scrolling up and down on the page)Fix
idleIntervals
outside the loop. Because we want to remember the number of intervals it was free before flushing out the data.bucketsVisited
to track buckets we have already visited. So that we don't go through the data again for which we didn't see any improvementsonBeacon
to remove only the data that we have seen. But ifc.tti
was calculated then flush as we use to before.