On a hospital campus, a patient-portal waterfall shows one third-party scheduling script consuming most of the page load while WAN loss counters stay quiet. What should the analyst treat as the cause?
Select an answer to reveal the explanation.
Short Explanation
A traffic jam caused by one oversized truck is not a broken highway, and you fix the truck. Treat the third-party scheduling script that dominates the waterfall as the cause, especially while WAN loss stays quiet. A loss alarm, a hijack conclusion, or a QoS change explains a different picture than the one this waterfall draws.
Full Explanation
A browser waterfall attributes load time to objects. When one third-party scheduling script consumes most of that time and the WAN loss counters for the same period stay quiet, the cause to treat is that script, not a path-loss event the counters do not show. A loss alarm on the WAN circuit into the hospital data center would fit if the waterfall were short and the path showed loss, and the reported facts are the opposite pair. A DNS hijack of the portal name inferred from that script delay jumps from a slow object to an integrity event, and a long script bar does not show that the portal name resolves to an unintended address. A QoS policy change on the campus edge for that portal traffic is a capacity action for congestion or marking, and it does not remove a third-party object that dominates an otherwise quiet path. Exam caveat: waterfall questions want the bar that accounts for the time, and a security or QoS label is a distractor when the trace shows a slow object. Operational check: sort the waterfall by time, confirm the scheduling script is the dominant bar, and confirm WAN loss for that interval is quiet before opening a circuit or QoS change.