EnterraHost
A traceroute online answers the question ping cannot. Ping tells you the round trip took 240 milliseconds. A trace tells you that 30 ms of it was Cape Town to Frankfurt, 190 ms was Frankfurt to a congested peer, and the last 20 ms was the server waking up. Same measurement, opposite usefulness.
You can run one from five regions without an account. This is how to read what comes back.
What a traceroute online actually does
Every IP packet carries a time to live. Each router that forwards it subtracts one, and a router that reaches zero discards the packet and sends back an ICMP Time Exceeded message naming itself. That message is the entire trick. Send a packet with a time to live of one and the first router answers. Send one with a time to live of two and the second router answers.
A traceroute just does that thirty times in a row with a rising counter, and writes down who replied each time. Three probes go out per hop, so a single hop shows three round trip times rather than one.
That design has a consequence you need to hold onto. A hop only appears because that router chose to answer. The reply is optional, it is often rate limited, and it competes with real forwarding work on a busy router. A missing hop is information about a router's configuration. It is not automatically information about your traffic, which is still being forwarded through it.
Reading the output, hop by hop
Run a trace from the region your users are in. Latency is mostly distance, so a trace from Sydney to Frankfurt describes a journey nobody in Frankfurt is making.
Read down the numbers and watch for the step, not the total. Each hop should add a little. A hop that adds 150 ms in one jump is the link to examine, and now you know which operator owns it because each row carries the autonomous system number and the network name behind that address.
Then read the three times within a hop. Three probes fired milliseconds apart should agree. When they swing, that link is queueing, and queueing is what makes a call stutter while an average still looks fine. The average is the least interesting number in the row.
A hop can also be a carrier grade NAT address, the kind an ISP uses to share one public address among many customers. Those carry no location and no network at all, which is normal rather than broken. A hop that never replies keeps its place in the list and shows as a timeout. Where the silence sits matters. One silent router in an otherwise healthy path is routine. Silence from every hop after a certain point, with the target never reached, is where you stop reading and start asking.
IPv4 and IPv6 are different paths
Run the trace twice, once on each protocol. They are separate networks run by separate teams, and a clean path on one says nothing about the other. A dual stack site that looks healthy over IPv4 can have an AAAA record pointing at a path that drops traffic. Tracing the v6 route is the only way to see that.
If you have not checked whether your own connection and site even speak IPv6, that is a separate question with its own test.
Where the location column comes from
Every hop is labeled with a country, a network name and an ASN, looked up from a MaxMind database. Treat it as a strong hint rather than a fact.
GeoIP databases map address blocks to the place the block is registered and routed, which is not always the place the hardware sits. Carriers register large allocations at a head office and then use them across a continent. Anycast services announce the same address from dozens of cities, so the same IP can be answered from Johannesburg for one visitor and Frankfurt for the next. A backhaul link means a router physically in one city can carry an address registered in another.
The ASN and the network name are the trustworthy half of that cell. They come from BGP registration and they tell you whose equipment you are looking at, which is the part you need when you have to raise it with somebody. Use the country to orient yourself, and do not argue with a carrier about the city.
Pair it with a ping
The two tools answer different halves of one question, so run them in that order. Ping first, because it is fast and it tells you whether there is a problem at all, and because loss and jitter across several probes are easier to see in a summary than in a hop list. If the average looks wrong, trace the same target from the same region and the hop where the number jumps is your answer.
If ping reports loss, trace it before you blame the far end. Loss that starts at hop four and continues to the end is a problem in the middle of the network, and the target server never saw those packets.
When a trace finishes cleanly and the site is still slow, the network is not your answer. Check the server and its certificate instead, which will tell you what the host presents and how quickly it replied.
What a trace cannot tell you
It stops at the edge of a CDN. A large site answers from a cache close to you, so the trace ends there and says nothing about the origin behind it. Two visitors in different cities tracing the same hostname legitimately get different paths, because they really are hitting different machines.
It also cannot see past a tunnel. Traffic inside a VPN is encapsulated, so the hops you see belong to the tunnel, not the path underneath it.
Traceroute times also measure the path to each router's control plane, not to the data plane. A busy router deprioritises those replies, so a hop can show a large time while forwarding your packets perfectly well. If every hop after it is fast, that hop is describing its own CPU. The end to end number is the one that matters to a visitor.