Your Server-Rendered App Doesn't Know Who It's Talking To

We discovered that 75% of our React SSR traffic wasn’t human. Instead of making rendering faster, we changed who gets rendered. This talk shares practical traffic-aware SSR patterns that reduced our Node fleet 8× while keeping pages fast, fresh, and SEO-friendly. Most SSR architectures make one assumption: every request deserves the same rendering pipeline. In production, that assumption gets expensive. While analyzing our platform, we found only ~25% of incoming traffic behaved like real users — the rest was search crawlers, AI crawlers, and scrapers, all consuming the same SSR resources as humans. Instead of asking how to render faster, we asked which requests actually deserve server rendering. I’ll cover how we classified traffic into humans, search crawlers, AI crawlers, and scrapers; built traffic-aware cache keys; applied different caching strategies per segment; safely bypassed cache for personalized experiences; reduced unnecessary SSR proxy work during client-side navigation; kept long-lived crawler caches fresh via event-driven invalidation; and why vertical CPU scaling beat horizontal pod scaling for this workload. These changes took our average production footprint from ~400 Node SSR pods to ~50 — cutting infrastructure cost significantly while absorbing rising crawler traffic (including ChatGPT, Claude, Perplexity, and traditional search engines) without increasing origin load. The implementation is a custom React SSR platform, but the principles apply equally to Next.js, Remix, or any server-rendered app.