The Benefits of Server Side Rendering Over Client Side Rendering • Hacker News Board

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#21

Post by matthewmacleod » Sun, Mar 25, 2018, 8:12 PM UTC

hartator wrote: post #14

matthewmacleod wrote: post #13

I tried—I really did try—to use server-side rendering for every project I've worked on. I find it really unpleasant when I hit a site, like a blog or something, which has almost entirely static content and yet it still rendering it locally. The experience is objectively worse, and I had no interest in making that the case for my users. But there's a middle ground in practice. Public-facing website that users might hi…

Can you elaborate? My understanding is just having the initial version of your components server-sided rendered, not all of it. Then JS takes over when it's loaded. It shouldn't change much to your existing code.

Yeah, in theory it's pretty simple. If you're using Javascript on both the server and client, it's definitely easier. But I guess I'm conflating server-side rendering with "pages that don't require Javascript to work", which is definitely more work.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#22

Post by migueloller » Sun, Mar 25, 2018, 8:15 PM UTC

> SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. Let’s say that it takes you 500ms to SSR your page, that means you can at most do at most 2 requests per second. BIG CONSIDERATION

If your `renderToString` is taking 500ms you should really consider using `renderToNodeStream` [1]. It will significantly reduce TTFB and runs asynchronously, letting your Node.js server handle more incoming requests. This [2] blog post goes into more detail.

Also, if you don't want to use streams, Rapscallion [3] provides an asynchronous alternative to `renderToString`.

[1] https://reactjs.org/docs/react-dom-server.html#rendertonodes...

[2] https://zeit.co/blog/streaming-server-rendering-at-spectrum

[3] https://github.com/FormidableLabs/rapscallion

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#23

Post by pjc50 » Sun, Mar 25, 2018, 9:02 PM UTC

migueloller wrote: post #22

> SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. Let’s say that it takes you 500ms to SSR your page, that means you can a…

> `renderToString` is taking 500ms

What baffles me is that this is a long time. In that time, you've got about a billion CPU instruction executions. If you include GPUs, they can render multiple frames of complex scenes to million+ pixel buffers in that time. And people are having trouble rendering a string?

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#24

Post by tetha » Sun, Mar 25, 2018, 9:03 PM UTC

migueloller wrote: post #22

> SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. Let’s say that it takes you 500ms to SSR your page, that means you can a…

Ah. I was wondering about that. Running multiple nodejs instances won't fix the impact of long-running synchronous methods in the event loop on other requests processed in the same instance. It'll just reduce impact, because you reduce the relative percentage of other requests being held hostage by a bad request.

Unless you can use your loadbalancing to split requests with a risk of long-running synchronously tasks away from instances doing fast work. We're doing something like this - we got some really ugly legacy code around, which tends to abuse and overuse the application servers JDBC pool regardless of how we tune it. This causes every other request on that instance to crash and burn. This becomes even more fun if a customer retries the same request 20x and the load-balancer does round-robin. So we route the bad requests to a single martyr instance and everything works fine again except for this broken old code.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#25

Post by tetha » Sun, Mar 25, 2018, 9:09 PM UTC

pjc50 wrote: post #23

migueloller wrote: post #22

> SSR throughput of your server is significantly less than CSR throughput. For react in particular, the throughput impact is extremely large. ReactDOMServer.renderToString is a synchronous CPU bound call, which holds the event loop, which means the server will not be able to process any other request till ReactDOMServer.renderToString completes. Let’s say that it takes you 500ms to SSR your page, that means you can a…

> `renderToString` is taking 500ms What baffles me is that this is a long time . In that time, you've got about a billion CPU instruction executions. If you include GPUs, they can render multiple frames of complex scenes to million+ pixel buffers in that time. And people are having trouble rendering a string?

Hm, I'd guess, it's latency to backend servers. Cores are plenty fast for just about every language.

If you have a good network between systems, each request of any form to a backend service will introduce at least 0.5 ms of response time due to datacenter RTA, so once you hit 250 queries, that's that. And 250 queries are just one n+1 problem somewhere.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#26

Post by tootie » Sun, Mar 25, 2018, 9:46 PM UTC

angersock wrote: post #12

tootie wrote: post #7

Earlier quoted context omitted.

Early attempts were pretty ham-fisted and only really useful for backoffice web apps with captive users and LAN connections. The past few years have seen a lot of advancement in tools like webpack to streamline how much code gets served for a given page.

And for a login page with what is effectively a form element with two input fields that IS is overkill.

Well, what was likely happening is that the entire application was bundled into a giant JS file that was served up on every page regardless of how much of it you needed.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#27

Post by syrrim » Sun, Mar 25, 2018, 10:09 PM UTC

tetha wrote: post #25

pjc50 wrote: post #23

Earlier quoted context omitted.

> `renderToString` is taking 500ms What baffles me is that this is a long time . In that time, you've got about a billion CPU instruction executions. If you include GPUs, they can render multiple frames of complex scenes to million+ pixel buffers in that time. And people are having trouble rendering a string?

Hm, I'd guess, it's latency to backend servers. Cores are plenty fast for just about every language. If you have a good network between systems, each request of any form to a backend service will introduce at least 0.5 ms of response time due to datacenter RTA, so once you hit 250 queries, that's that. And 250 queries are just one n+1 problem somewhere.

The OP says the call is CPU bounded, which suggests that even if time is spent on the network, it is a minority of the total time.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#28

Post by moltar » Sun, Mar 25, 2018, 10:30 PM UTC

tetha wrote: post #5

Hm, any thought on the performance/throughput consideration? I'm not experienced with Node.JS, but something hogging the main event loop of an asynchronous server with a long computation sounds horrible. It'll mangle your throughput, and it'll create some really strange latency spikes for unrelated requests, because the slow computation blocked the event thread from delivering the response of another request. Is this…

Keep in mind that only rendering blocks, not the entire request. Your database calls and other stuff is still non blocking. The actual rendering time is measured in tens of ms in my experience, but then I’m not Walmart. But at the same time I haven’t seen any pages in Walmart that render for half second.

I think you are doing something wrong if your tender time is more than a few ms.

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#29

Post by meesterdude » Sun, Mar 25, 2018, 11:01 PM UTC

matthewmacleod wrote: post #20

meesterdude wrote: post #16

Earlier quoted context omitted.

> If you aren't using Node on the server, it's even more complex. stopped reading after this. clearly just babble with no real argument to be made.

I'm sorry if I wasn't clear, but I don't think it's an argument without merit. I mean that if you want to build a UI in the manner described in the article—where you essentially use a JS UI framework to render the application server-side, and subsequently make it interactive on the client side—then doing so without the server being Javascript is more complex. I have direct experience of doing this – I built a complex…

> then doing so without the server being Javascript is more complex.

why? What does the server being javascript do for you that no other server can do to reduce the complexity?

Re: The Benefits of Server Side Rendering Over Client Side Rendering

#30

Post by DougWebb » Mon, Mar 26, 2018, 3:44 AM UTC

ww520 wrote: post #18

DougWebb wrote: post #15

Earlier quoted context omitted.

I've always found that nearly all of the time spent when requesting a page of SSR'd content (whether that be a full page or a rendered component returned to an AJAX request) was spent in the processing before the render happens. Given that, the added complexity of CSR has never been worth it for me. This is situational, I think. My work mostly involves applications that do significant back-end processing for most req…

While the rendering time is minimal, the rendering code still blocks to wait for the underlying processing code, making the throughput low.

That doesn't make sense, unless you're talking about a specific framework that has bad performance characteristics.

Let's say you've got a request that does SSR and takes 500ms, with 450ms of that time spent processing the request and 50ms spent rendering the response. If you switch to CSR, you still have to wait 450ms to process the request, and you've got to serialize the response data (eg: render it to a more concise format than html) which is going to take some of that 50ms you're trying to save. So, where is the blocking you're talking about? How does CSR make it go away?

What you wrote sounds like you're describing a singleton that handles all rendering for all requests, and can only handle one request at a time. If that's the case, your framework is a toy and you need to ditch it for something that can handle multiple concurrent requests independently of each other.