A strong answer. “I'd start by defining slow, because ‘slow’ from a user and ‘slow’ on a link are different measurements. Is it slow to connect, slow to first byte, or slow throughout? Connect-time points at DNS or handshake, first-byte at the server or a proxy, and throughout at throughput or loss.

Then I want to reproduce it with a measurement that resembles the application rather than a ping — ICMP is deprioritised on plenty of gear, so a clean ping means very little. A TCP-based probe to the actual port, run continuously from the affected site, gives me latency and loss over time rather than a snapshot of a moment when it was fine.

Then the specific things that produce intermittent slowness rather than constant slowness. Loss with retransmits — even a fraction of a percent destroys TCP throughput over a long path, and it is invisible in a utilisation graph. Micro-bursts — interface counters averaged over five minutes look idle while the buffer is overflowing for milliseconds; I need interface discards and queue depth, not average utilisation. Asymmetric routing where the return path differs and traverses something congested or a stateful device. MTU and fragmentation, which produces the classic ‘small requests work, large ones hang’. A middlebox — firewall, proxy, TLS inspection — which is very often the actual answer and is not thought of as network.

And I would get a packet capture at both ends before concluding anything. Discards and retransmits are facts; everything else is inference.”