Onion service performance is server-side: where the milliseconds go and what operators can actually tune
When an onionsite feels slow, the reflex is to blame the Tor network. That is fair only up to a point. A hidden service never talks to visitors directly, and every connection is assembled from relays chosen by both sides, but a real share of the waiting is manufactured on the service's own machine, in how Tor maintains the plumbing in front of the web backend. Knowing which half is which decides whether tuning helps or merely relocates the blame.
Where the milliseconds go
The Tor Project's protocol overview counts a completed onion connection at six relays - three picked by the client, three by the service, spliced at a rendezvous point that then "simply relays (end-to-end encrypted) messages from client to service and vice versa" (Tor Project, onion service protocol). Before that circuit exists, several round trips are already spent: the client fetches the service's signed descriptor from a distributed hash table, builds a path to one of its introduction points, and negotiates the rendezvous. None of that is backend time, yet all of it lands on the visitor's stopwatch. The service side also carries a standing cost no client pays. Introduction points hold long-term anonymized circuits from the service, and the Tor manual puts the default pool at three introduction points, expandable to twenty for a v3 service. Because those relays are the only address the service has, they cannot be allowed to quietly disappear - a failing introduction point forces the service to build another three-hop circuit and re-publish its signed descriptor, work that shows up as colder, slower first loads.What an operator actually controls
Tor exposes a short list of knobs, narrower than most performance folklore admits:- Crypto headroom. The handshakes that introductions and rendezvous generate are decrypted by a pool of crypto workers; the manual describes NumCPUs as "how many processes to use at once for decrypting onionskins and other parallelizable operations." A CPU-starved service feels slow in exactly the places an operator can fix.
- Introduction pool size. HiddenServiceNumIntroductionPoints defaults to three, and more intro points spread introductions over more relays at the price of more standing circuits.
- Circuit freshness. MaxCircuitDirtiness defaults to ten minutes, and the manual notes that for hidden services the age counts from the last time a circuit carried traffic. Raising it reduces rebuild churn; lowering it trades more builds for fresher paths.
- Software currency. Congestion control arrived in Tor 0.4.7 in 2022, and the Tor Project was blunt that "Users of Tor versions 0.4.7 and above will experience faster performance when using Exits or Onion Services that have upgraded to 0.4.7" - an onion service on an older release caps every visitor at legacy flow control (Tor Project blog).
The single-hop temptation
The oldest performance debate in this corner of Tor is whether the service needs three hops of protection at all. Proposal 260, drafted in 2015 by a group including Roger Dingledine and Paul Syverson and implemented in Tor 0.2.9.3-alpha, describes "rendezvous single onion services" that "trade service-side location privacy for improved performance, reliability, and scalability," building one-hop circuits to introduction and rendezvous points and cutting the path to "4 rather than 6" relays. The switch still ships: HiddenServiceSingleHopMode is documented as experimental and non-anonymous, making the server "easily locatable" while "clients remain location-anonymous." The trade is unsentimental. A single onion keeps its .onion address and its visitors' anonymity but surrenders the operator's own location hiding - and the proposal's authors warned that each additional flavour of onion service "splits the anonymity set." The default design therefore survives: single-hop remains an opt-in tool for operators who can accept exposure, which is a judgment Tor deliberately leaves outside the protocol.Why big properties run tuned backends
Long-lived onion properties - search engines, mirrors, directories - converge on the same shape: thin Tor frontends, deliberately static or cached backends, and load spread across instances. Proposal 260 even notes that a rendezvous single onion service "can load-balance over multiple rendezvous backends." None of it shortens the path; it minimizes the one segment the operator owns so the six-relay trip is the only meaningful wait left. Tor Metrics measures onion traffic by extrapolating from statistics reported by relays acting as rendezvous points - that tier is literally where the visible load lives (Tor Metrics).What can and cannot be fixed
"Because onion services paths are more than twice the length of Exit paths (and thus more than twice the circuit latency), onion service throughput will always have less than half the throughput of Exit throughput." (Proposal 324)Operators can fix crypto headroom, introduction pool size, software currency and backend weight. They cannot fix path length, that day's circuit build times, relay congestion, or the client's own guard rotation. The honest reading: a first uncached page load that takes seconds is not a broken site - it is descriptor lookup, introduction and rendezvous setup being paid in full - while steady requests on a warm circuit should sit close to the backend's own response time plus network transit. If a service stays slow after the first page, the operator probably has room to act. If it only feels slow at midnight peaks, that is the network's shift, not the backend's - the pattern documented in our earlier field notes on onion latency variance. On the server side the wins are real but bounded: tune what torrc owns, keep the origin light, and stop expecting the path to be shorter than the protocol makes it.