Whether a slow page means anything
The statement: the site is slow, so it is dying. It might be. It might also be your circuit, and the two feel the same from a chair.
Bucket: DEPENDS
It depends on which of about six causes you have, and five of them produce the same symptom. Slowness is not a measurement of anything on its own.
The six causes
- Your circuit happens to run through slow or overloaded relays.
- The Tor network as a whole is under strain.
- The service is under load from a lot of users.
- The service is under attack, which looks like load.
- The service is partly broken, so some pages work and others hang.
- Your own connection is the problem.
None of these announces itself. All of them produce a page that takes too long and then maybe arrives.
Cheap ways to separate them
| Test | What it separates |
|---|---|
| Build a new circuit for the site | Cause one from everything else |
| Load a different onion service | Causes one and two from three to five |
| Load an ordinary site | Cause six from the rest |
| Try a second address from the list | Per service problems from shared ones |
| Try a different part of the site | Cause five from three and four |
Four tests, a couple of minutes, and you have narrowed six causes to one or two. That is far better than any inference from how slow it feels.
What you can see and what you cannot
You can see your own circuit, whether other onion services respond, and whether your ordinary connection works. You cannot see the service's load, whether it is under attack, or whether the operator is in the middle of something. Those three are invisible and no amount of waiting reveals them.
This is the classic case of treating an invisible variable like a controllable one. Refreshing does not measure server load. It adds to it.
What people get wrong
They read slowness as a story about the market's health. It is more often a story about three relays they were unlucky enough to be routed through. Onion connections use more hops than ordinary Tor browsing, so there is more to go wrong and more variance between attempts.
They also conclude too fast from one address. Because each mirror is a separate key, one being slow is genuinely uninformative about the others.
What the symptom does not distinguish
Load and attack look the same from a browser. So do a partly broken service and a heavily loaded one. Nothing you can observe from outside separates them, and people spend a lot of energy arguing about which it is on the strength of no evidence at all.
The distinction also does not matter for what you do next. All three call for the same response, which is to wait or to come back. Diagnosing them further is a hobby rather than a step.
When slowness does mean something
When it is consistent across fresh circuits, across all three addresses, while other onion services respond normally. That combination narrows things considerably. It still does not tell you which of load, attack or breakage you are looking at, and that distinction is not available to you.
At that point the honest move is to stop diagnosing and come back later. There is no further information to be extracted by trying again in ten seconds.