The Performance Cost of Server Side Rendered React on Node.js
1–10 of 134 posts
Re: The Performance Cost of Server Side Rendered React on Node.js
#2I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
Re: The Performance Cost of Server Side Rendered React on Node.js
#3I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
[deleted]
Re: The Performance Cost of Server Side Rendered React on Node.js
#4I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
Sure, but every user has to do that initial page load. If all initial page loads are slow and expensive, it affects the user experience and costs money.
Also, if you start getting requests faster than you can do the initial render, each subsequent user has to wait in line longer than the one before. Your server-side framework won't even show you how long people waited for a TCP connection.
Re: The Performance Cost of Server Side Rendered React on Node.js
#5well wasn't that clear? Isn't something like a Template Engine quite CPU intensive? Things were node.js performce poorly?
Re: The Performance Cost of Server Side Rendered React on Node.js
#6[deleted]
Re: The Performance Cost of Server Side Rendered React on Node.js
#7I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
Sure, but every user has to do that initial page load. If all initial page loads are slow and expensive, it affects the user experience and costs money. Also, if you start getting requests faster than you can do the initial render, each subsequent user has to wait in line longer than the one before. Your server-side framework won't even show you how long people waited for a TCP connection.
But they're going to have to wait for the initial page load either way, whether it's rendered server side and sent over or they're shown some static content until its rendered client side?
Re: The Performance Cost of Server Side Rendered React on Node.js
#8Earlier quoted context omitted.
Sure, but every user has to do that initial page load. If all initial page loads are slow and expensive, it affects the user experience and costs money. Also, if you start getting requests faster than you can do the initial render, each subsequent user has to wait in line longer than the one before. Your server-side framework won't even show you how long people waited for a TCP connection.
But they're going to have to wait for the initial page load either way, whether it's rendered server side and sent over or they're shown some static content until its rendered client side?
They do, but the load will be spread among clients. The issue here is the load on the server.
Re: The Performance Cost of Server Side Rendered React on Node.js
#9So I thought the entire point of SSR was to speed up initial page load - if you pre-render all the static parts of the page, including what happens after routing, but before any API calls, so that your webserver can cache that static HTML for that route and serve it up. What this means is that the user immediately sees much more of a rendered HTML page, rather than seeing a blank page for 2 seconds and having to wait to download and run a massive JS bundle first.
Re: The Performance Cost of Server Side Rendered React on Node.js
#10I thought the idea was to render it server side just once, then have the client take over for all future requests? In which case it's 10x slow for the first page load, but all future requests are just hitting API endpoints and can be fairly fast?
Correct, except that initial app load time for un-cookied users with cold browser caches is a critical metric, since it largely determines whether they'll keep using your app. Fortunately, those are the scenarios where server-side caching can have a decent benefit, since you're essentially rendering the same view to all such users.