On event days, a stadium ticket page shows a waterfall in which one CSS file must finish before any later resource starts. Which finding should the team treat as the cause?
Select an answer to reveal the explanation.
Short Explanation
One closed gate can hold every car even when the highway beyond it is empty. You treat the blocking CSS file as the cause, because the waterfall shows later resources waiting on it. A WAN loss alarm, a DNS hijack story, or a QoS change do not explain a file the browser must finish before it continues.
Full Explanation
On a browser waterfall, a parser-blocking stylesheet holds subsequent resource requests until that file finishes, so the rest of the page cannot start even when the path behind it is fine. The blocking CSS file that must finish before any later page resource starts is the cause on this event-day ticket page, because the waterfall shows that gate explicitly. A WAN loss alarm opened because that CSS file was slow to finish on event day treats a blocking object as packet loss. Loss would show as drops on the path, not as every later request lined up behind one stylesheet. A DNS hijack conclusion based only on the delayed request for that CSS file confuses a late start with a forged name. Nothing described here shows the name resolving to an unexpected destination. A QoS change aimed at the CSS object while the rest of the ticket page waits behind it adjusts forwarding for a file the browser is required to finish first, and it does not remove the blocking relationship the waterfall already shows. Exam caveat: the object that gates later requests is the finding, even on a busy event day, unless the path itself shows loss. Operational check: on an event-day capture, confirm later resources begin only after that CSS file completes.