Page Loading Delays for My Website When Accessed via Tor Browser

Hello Tor Project Community,

I am currently experiencing a persistent and highly reproducible loading issue with my Culver menu website, specifically when it is accessed through Tor Browser. The core problem is extremely slow page load times that make the website almost unusable for Tor users. When accessed through a standard browser on a normal connection, the site loads within two to three seconds, but when accessed through Tor, the same pages can take anywhere from thirty seconds to over a minute to fully render. In some cases, the page partially loads and then stalls indefinitely until manually refreshed. This issue appears consistently across different Tor circuits and exit nodes, suggesting that it is not a single-node anomaly but something more systemic in how my website interacts with Tor traffic.

The website itself is a dynamic menu platform that displays categorized food items, images, and pricing data pulled from a backend API. While the total page weight is not excessively large by modern standards, it does include compressed images, JavaScript bundles for interactivity, and asynchronous data fetching for menu updates. I have optimized images, enabled server-side compression, and minimized JavaScript where possible, yet the performance degradation through Tor remains extreme. Network monitoring indicates that the Time To First Byte (TTFB) increases dramatically when requests originate from Tor exit nodes, which suggests that either the routing overhead or server-side response handling for Tor traffic is contributing to the delay.

What makes this problem particularly confusing is that the slowdown is not limited to heavy assets such as images; even simple HTML responses experience significant latency when accessed via Tor. I have tested by creating a stripped-down version of a single menu page containing minimal styling and almost no scripts, and the load time through Tor is still disproportionately high compared to standard browsers. This leads me to believe that the issue may relate to how my hosting server or firewall processes Tor exit node IP addresses, potentially introducing additional security checks, rate-limiting, or automated traffic filtering that affects response times. However, I have not intentionally configured any Tor-specific blocking rules, and there are no explicit firewall errors visible in my logs.

Another important detail is that once the initial page finally loads, subsequent navigation between internal pages remains slow, even though caching headers are properly configured. Normally, returning visitors should benefit from cached static resources, but through Tor, each request seems to behave like a fresh, uncached visit. I am unsure whether this is due to Tor Browser’s privacy design disabling certain caching mechanisms, or if my server’s cache-control headers are not being interpreted as expected in the Tor environment. The cumulative effect is that Tor users experience an unusually degraded browsing session compared to non-Tor visitors, which raises concerns about accessibility and fairness of access.

From the server perspective, I have reviewed logs during Tor-based access attempts and noticed longer processing durations for requests associated with Tor exit IP addresses. The server does not show outright blocking or 403 errors, but response times appear consistently extended. There are no visible CPU or memory spikes during these periods, so resource exhaustion does not appear to be the cause. This pattern makes me question whether there are DNS resolution delays, TLS handshake overhead, or additional verification layers that are amplified when traffic routes through the Tor network. However, I lack sufficient expertise in Tor’s internal routing and performance characteristics to definitively identify the bottleneck.

I am seeking guidance from the Tor community to better understand whether this type of loading degradation is typical for dynamic websites accessed via Tor, or if there are known server-side configurations that inadvertently slow down Tor traffic without explicitly blocking it. I would greatly appreciate advice on diagnosing whether the issue lies in Tor’s multi-hop routing latency, my hosting provider’s treatment of exit node IP ranges, TLS negotiation behavior, or caching interactions specific to Tor Browser. My goal is not to bypass Tor’s privacy safeguards but to ensure that users accessing my Culver menu website through Tor can experience reasonable loading performance without compromising security or privacy standards. Any technical insight, debugging suggestions, or configuration recommendations would be extremely helpful. Thanks!

It is known that browsing over Tor is generally slower.

Are you talking about the same website as in this post? In that case, I did not experience any loading issues when using the Tor browser - it loaded correctly and in less than 10 seconds.

I did notice you use Cloudflare. This could mean that Cloudflare is doing some extra security checks to verify the request or is rate-limiting the IP of your exit-node.

My advice is to serve your website as an onion-service. If configured correctly the Tor browser can detect if there is a onion-url available for your clearnet website and will show the visitor the option to use that instead. An onion service will be faster then a clearnet website. Cloudflare supports it: https://blog.cloudflare.com/cloudflare-onion-service/

I’d echo @NielD, I tried 10 connections each with a new identify and mostly loading time was under 10s. Worst was 18s, but my connection goes through a VPN.

Your point about Cloudflare is especially interesting. I am indeed using Cloudflare, and I had not fully considered how its security layers (Bot Fight Mode, rate limiting, managed WAF rules, TLS fingerprint checks, etc.) might interact with Tor exit nodes. Even if requests aren’t blocked outright, additional verification or challenge logic could be increasing TTFB without producing visible errors. That would align with what I’m seeing extended response times but no 403s or explicit firewall denials.

The onion service suggestion is also something I hadn’t seriously explored before. If Tor Browser can automatically detect and prioritize an onion endpoint for the same clearnet site, that could significantly reduce the latency introduced by exit nodes and avoid Cloudflare’s edge-layer scrutiny entirely. From what I understand, onion services remove the exit node from the equation, which would eliminate one major variable.

The total path length of a circuit to an onion service is double the length then a circuit to a clearnet website. I suggested it could be faster in your case since Cloudflare will support Tor clients instead of working against by security checks.