I'm all for SSR so agree with the sentiment of this post but browser HTTP requests don't manage a single TCP connection per request. Not since HTTP/1.0
HTTP/1.1 uses persistent connections by default so TCP connections are reused for multiple requests.
HTTP/2 goes a step further by providing multiplexing, allowing multiple requests to perform on a single connection at the same time.
"Server rendering is stupid. It's only there to increase bills by cloud providers"
Increasingly tired of seeing this sentiment so I'm going to explain why this is a really dumb take.
1. SSR costs are low
The cost of turning JSON into HTML is not particularly large. Most SSR benchmarks don't include actual I/O, i.e. database calls.
Render times in modern frameworks like Next.js are measured in milliseconds, rarely breaking 20ms. A basic DB query will take 10x that. Auth will take similar.
There's also a ton of opportunities to skip the render altogether. If the data isn't behind an auth wall, it can usually be cached and invalidated on write rather than read. Now you only have to pay for CDN bandwidth
2. SSR reduces other cloud costs
Let's say you have a page with 5 components that need data to render. If all 5 make an API call, you now have to manage 5 separate requests on the server. Each request has it's own:
- TCP connection setup and teardown overhead
- Authentication/authorization check and token validation
- HTTP header processing and parsing
- Database connection from the connection pool
...and much more
"But theo! I batch my requests!" Sure you do. Link me your fully client-rendered site with zero waterfalls. If you're not using Relay, you're almost certainly making > 1 request client-side. And don't get me started on revalidation 🙃
With SSR, you can generate all of the page content in a single request. With out-of-order streaming (built into most modern frameworks), you can send down the static-y parts immediately and stream the rest later when it's ready. ALL WITHOUT MAKING A NEW CONNECTION.
It is genuinely hard to fathom a world where the cost of SSR is higher than all the costs saved by reducing all of this per-request overhead. The only way it would be cheaper to avoid SSR is if you're building a toy app with no actual data.
3. SSR provides a better experience (not just SEO)
One of the most common misconceptions I see around SSR. "I don't need SEO, why do I care?"
Even if you only use SSR to render a shell, and do everything else client side, you still get:
- route-specific metadata
- route-specific js bundles
- route-specific styles
- route-specific loading states (my favorite)
This means the user sees something faster, more meaningful, and all while loading LESS javascript. This seems like an obvious win to me.
Once you're rendering on the server, doing the "right thing" for your users becomes significantly easier. I have a few videos where I talk about this, but you should definitely check out the SVG example in "My Website Is Airplane Proof" if you want to see how deep it goes.
If you're not building a toy project, SSR saves you money.