Why Some Onion Sites Are Slower Than Others (And When to Wait)
What actually causes Tor hidden service slowness, why retrying the same address makes it worse, and the small set of decisions that fix most stalls.
If you spend any time on Tor hidden services, you have hit a session where one site loads in two seconds and another sits on the connection screen for thirty. The instinct is to blame the slow site. Most of the time, the slow site is fine and your circuit is the bottleneck. This page is a short tour of where the latency actually comes from, what you can change, and what is wasted effort.
Where the seconds come from
A Tor connection passes through several relays before it reaches the destination. For a hidden service, the path is longer than for a clearnet site: your circuit ends at a rendezvous point, the service's circuit ends at the same rendezvous point, and the two circuits are spliced. Every relay adds a small fixed delay plus a variable component based on its current load. Multiply that by six or seven relays total, and a working hidden service connection lives in a range of two to ten seconds for the first page load.
That is the baseline. Slowness beyond it usually comes from one of three places: a congested relay in your circuit, a flood targeting the service's rendezvous points, or a slow back end on the service itself. The first two are transient and respond to changing the circuit. The third is the actual server, which you cannot do anything about.
Why retrying the same address makes things worse
When a connection stalls, the natural response is to refresh. On Tor, refreshing rebuilds the failed connection but on the same circuit. If the circuit is the problem, refresh inherits the problem. Refreshing also adds another connection attempt to the rendezvous point that is already under stress, which is the opposite of what you want during a flood.
The right action is to change the circuit. The Tor Browser menu has New Tor Circuit for this Site exactly for this case. It rebuilds the middle and exit (or, for a hidden service, the rendezvous chain) without changing your guard. Use it when a page is stuck and you have already waited fifteen or twenty seconds.
Why switching to a different mirror works
Many Tor services publish more than one onion address pointing at the same back end. The addresses live on different rendezvous chains, so switching from one to another is functionally the same as building a new circuit, but it also moves you off any specific rendezvous point that is under flood. When all three addresses in a published mirror set time out at once, the back end may genuinely be in trouble; when only one does, you are looking at network congestion that another address bypasses.
For the operator-side mechanics of why services publish a set rather than one address, see How Tor Hidden Service Mirrors Are Rotated.
What the back end can and cannot fix
Tor operators cannot speed up Tor. The latency is a property of routing through several relays. What operators can do is publish multiple mirrors (so a flood on one rendezvous chain is bypassed by others), keep the back end snappy (so the server-side response time is negligible compared to the network time), and avoid heavy JavaScript that adds round trips.
This is one of the reasons hidden services worth using tend to feel snappy at first load and slow only when the network is genuinely under pressure. The difference is server-side discipline, not Tor magic.
The simple workflow
When a Tor page is slow, do this in order. Wait fifteen seconds. If still stuck, choose New Tor Circuit for this Site from the browser menu. If still stuck after a minute, switch to a different address from the service's published mirror set. If all addresses in the set time out, the service is under flood; wait twenty minutes and try again. That sequence handles almost every Tor slowness you will see in normal use.
Related reading
For the three-hop circuit structure under all of this, see How Tor Circuits Are Built. For what happens during a real flood, see What Happens to a Tor Hidden Service During a Denial-of-Service Wave. For a maintained mirror set that updates as the rotation moves, the Nexus Market directory is a working example.