Content Delivery Optimization for Tor Hidden Services

HTTP/2 multiplexes multiple requests over a single TCP connection, eliminating head-of-line blocking and reducing connection establishment overhead. For a standard web page requiring 20-50 resources (HTML, CSS, JS, images): HTTP/1.1 uses multiple connections, each requiring Tor circuit setup. HTTP/2 sends all resources over a single Tor-circuit-backed connection. The round-trip savings are significant over Tor's high-latency circuits. Enable HTTP/2 in nginx: add http2 to the listen directive (listen 80 http2; - note: standard HTTP/2 typically requires TLS, but for .onion services, some configurations support h2c cleartext HTTP/2. Check nginx version compatibility). Configure upstream application servers to support HTTP/2 or HTTP/1.1 with keepalive (the nginx-to-application connection can remain HTTP/1.1 even if the client-facing connection is HTTP/2). HTTP/2 server push: push critical CSS and JS resources with the page HTML response to eliminate render-blocking resource request round trips. Configure pushes in nginx with http2_push /style.css; directives.

Caching eliminates repeated content fetches. Configure Cache-Control headers appropriately for each resource type: Immutable assets (versioned JS/CSS with content hash in filename): Cache-Control: max-age=31536000, immutable. These files never change once deployed (the hash changes when content changes, creating a new URL). HTML pages: Cache-Control: max-age=300, must-revalidate (5-minute cache, revalidation required). API responses: Cache-Control: no-store for personalized content, max-age=60 for public data endpoints. Server-side caching with nginx's proxy_cache: cache API responses at the nginx layer, serving cached responses without hitting the application server. This is particularly valuable for .onion services where the circuit is already established - serving from nginx cache is faster than proxy_pass to the application. Varnish cache: for complex caching rules, Varnish acts as a caching reverse proxy between nginx and the application.

Each external resource request adds a Tor round-trip. Minimize resource count: bundle all JavaScript into a single file (webpack, Rollup, Parcel), bundle all CSS into a single file (PostCSS, sass --style=compressed), and inline critical CSS (above-the-fold styles) directly in the HTML head. Inline small images as base64 data URIs in CSS (< 2 KB images). Sprite sheets combine multiple small images into one file. SVG sprites combine icon SVGs into a single sprite file referenced by symbol ID. Image optimization: convert PNG/JPEG to WebP (smaller file sizes at equivalent quality). Use appropriate dimensions - do not serve a 2000px image to display at 400px. The Squoosh CLI tool or ffmpeg converts and optimizes images in batch. For a typical page: reducing from 40 resources to 5-8 resources (1 HTML, 1 CSS, 1-2 JS, 3-4 images) dramatically improves load time over Tor.

Compression reduces transfer sizes, directly improving load times over Tor's bandwidth-constrained circuits. Gzip compression in nginx: gzip on; gzip_comp_level 6; gzip_types text/html text/css application/javascript application/json image/svg+xml. Brotli compression (superior to gzip for text): install nginx brotli module, enable with brotli on; brotli_comp_level 6; brotli_types text/html text/css application/javascript. Brotli achieves 15-20% better compression than gzip for typical web content. Pre-compress static assets at build time: generate .gz and .br files alongside originals, configure nginx to serve pre-compressed files when the client accepts the encoding (gzip_static on; brotli_static on;). Pre-compression eliminates CPU overhead during request serving - compression happens once at deploy time, not per-request. Binary compression: WebP images (for JPEG/PNG replacement), WOFF2 for fonts (superior to WOFF/TTF). The combined effect of pre-compressed Brotli text + WebP images + WOFF2 fonts can reduce total page weight by 60-75%.

Service Workers allow .onion web applications to cache resources and serve them offline or from cache before making network requests. This dramatically improves perceived performance: subsequent visits serve the app shell from cache instantly (before Tor circuit establishes) while fresh content is fetched in the background. Progressive Web App (PWA) architecture with a Service Worker: (1) App shell (HTML, CSS, JS framework) cached on first visit. (2) Dynamic content fetched via Tor on each visit. (3) If Tor circuit is slow, the cached app shell displays immediately while content loads. Tor Browser supports Service Workers in its standard security settings. In strict security mode, Service Workers may be disabled. Test with Tor Browser at various security levels. Service Worker registration: the .onion service must serve the manifest.json and service-worker.js files with appropriate MIME types and CORS headers. A well-implemented Service Worker can make a .onion web application feel nearly as responsive as a clearnet app for returning users.