>Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.

Isn't this the other way around? I mean a server is supposed to be fast enough to handle a lot of requests.

An individual server is more powerful than one client, but your client computing power multiplies by your user base.

Same reason DDoS attacks are generally more powerful than DoS attacks.

Power in numbers.

Well, servers often come with more but slower cores.

But servers have a much higher power budget compared to phones or most laptops. That's supposedly the target user base for SSR + hydration.

I don't think the purpose of SSR + hydration is to simply move the wait time from first render to server response, or that servers can somehow render faster. To fully yield the benefits you'd have to enable caching, so that the server spits out something without rendering and the client side can simply hydrate.

Caching is not something individual distributed clients can do, which is why the server is the only way able to reasonably take on this role. You can also easily configure nginx to serve just-in-time caching.

>Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.

I'm thinking about that Hacker News article, which had a laptop in the datacenter, because it was much faster on it.