search

akamai / boomerang

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

Spike in Time To Interactive (TTI) and Blocking Time #319

Closed sarah-h2g2 closed 3 years ago

sarah-h2g2 commented 3 years ago

We've a spike in TTI on our site. It stays for a few hours and then goes back to normal i.e. TTI goes over 10second and then back to below that mark. The Beacon Waterfall Dashboard shows Blocking Time for first request for every beacon during that period. The Time To First Byte (TTFB) is taking this Blocking time into its calculation and the TTI seems to always be relative to TTFB i.e.

Blocking Time 14s After sending request, server Response time is 300ms but TTFB will be shown as 11.33 sec and TTI would be shown as greater then 14.33 sec. It's happening to mostly users on Desktop using Chrome browser on Windows 10.

Questions: Is Blocking Time stalled time in the browser before a request could be sent? Can it affect TTI calculation? Why is TTI relative to TTFB when it's a totally separate metric from TTI?

bluesmoon commented 3 years ago

This sounds like it might be about mPulse rather than the opensource boomerang library. I'd recommend reaching out via your Akamai contact.

bluesmoon commented 3 years ago

If not, I apologise, but boomerang itself doesn't have a waterfall dashboard (or any dashboards)

sarah-h2g2 commented 3 years ago

@bluesmoon No worries, thanks for your response. Yes, it's happening in mPulse Waterfall Dashboard. I saw some open issues related to TTI so I thought it might be a related issue but I'll reach out to my Akamai contact to clarify it. Thank you.

nicjansma commented 3 years ago

@sarah-h2g2 I'm not sure if you got other clarification, but for some of your questions:

Is Blocking Time stalled time in the browser before a request could be sent?

Unfortunately, when Boomerang captures (and mPulse displays) blocking time, it's because the browser reported a period of no activity, without any details. It sounds like the blocking time is happening prior to responseStart? Can you share an example full beacon with all of the nt_* timestamps?

Can it affect TTI calculation? Why is TTI relative to TTFB when it's a totally separate metric from TTI?

TTI's start timestamp is navigationStart, so any delay along the way (e.g. TTFB or DOM delays) will affect TTI. Basically, TTI is defined as "how long after the user clicked to navigate was the next page interactive?", so it includes everything along the way that could go wrong.

nicjansma commented 3 years ago

Closing as there haven't been any updates, but please let us know if there's anything to follow up on