how/network
No packet comes back with the route inside it. To see the path, traceroute cleverly exploits TTL: it "kills" packets at each hop and collects the ICMP replies.
When a site "loads slowly," where is the bottleneck? On your end? At your ISP? On the backbone? Without visibility into the path this is blind guessing.
traceroute shows you every router on the path to the target server
plus the delay at each one. But how? Network packets do not carry
a "list of all hops" inside them, and routers are not obligated to reveal them.
The solution is the TTL trick. traceroute deliberately sends packets
that will die at a chosen router, then collects their "dying
notices" (ICMP time-exceeded). Each notice comes from a
specific router, and that is how the list is built.
Press ▶ and watch how 4 packets with increasing TTL produce the full path.
Between us and google.com sit several routers (usually 8-15). Which ones exactly we do not know, and ordinary packets do not answer this question.
The reply from google.com arrives as a "reply from google.com," with no
information about the intermediate hops. We need a different approach.
recap
What to remember:
traceroute probe has its own TTL:
1, 2, 3, 4... At TTL=N the packet dies at the Nth router, which sends
ICMP time-exceeded → traceroute learns the router IP and measures RTTtraceroute -I (ICMP) or
-T -p 443 (TCP to an open port)* * * at a hop mean the router does not reply. Often this is
a security policy: the router forwards traffic but stays silent on
ICMP. It does not mean the path is brokenIf you want to go deeper, there is an [[traceroute|extended article]] that covers mtr and tcptraceroute.