On a hospital campus, a browser waterfall shows a service worker serving a stale application shell, and the network row for that page does not run. Which conclusion fits this waterfall?
Select an answer to reveal the explanation.
Short Explanation
A cached map on the screen is not a drive you just took. You refuse to blame a network path the hospital waterfall did not measure, because a service worker served the shell and the network row did not run. The trap is a WAN loss alarm, a DNS hijack, or a QoS change for a trip that does not appear on the chart.
Full Explanation
A service worker can answer from its cache and hand the browser a stale application shell without the browser opening a network request for that page. This waterfall shows that pattern: the shell is served by the service worker, and the network row does not run. There is no path sample, no name lookup, and no transfer on the chart, so a path fault is not supported. The conclusion is the limit of the evidence: the shell came from the service worker, and the path was not measured. A WAN loss alarm needs a path the chart actually contacted; blaming loss for a row that did not run invents a measurement. A DNS hijack conclusion needs a lookup that returned an unexpected host, and this waterfall did not perform that lookup. A QoS change assumes page traffic was classified and delayed, but the chart did not carry that traffic at all. Exam caveat: do not assign loss, a hijack, or a class-of-service problem to a hop the waterfall did not record, even when the shell looks wrong. Operational check: confirm the shell is marked as served by the service worker and confirm the network row is absent before you open a path ticket for a fetch that did not happen.