Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?
How do you do that with dynamic content?
The Performance Cost of Server Side Rendered React on Node.js
41–50 of 134 posts
Re: The Performance Cost of Server Side Rendered React on Node.js
#42Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?
That would be one way of using it. Though practically speaking a very limited way of doing it and not very useful for a lot of dynamic sites.
Re: The Performance Cost of Server Side Rendered React on Node.js
#43Earlier quoted context omitted.
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.
If all first time users see the same thing, why not serve a precompiled static html that then gets taken over by React. Isn’t that the whole point?
> If all first time users see the same thing
That's a big, important, if.
Re: The Performance Cost of Server Side Rendered React on Node.js
#44I 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.
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
This is "bounce before document.ready()?" How does it compare to "bounce before ad networks/API calls finish" and "bounce before end of autoplay video?"
I'm thinking that with all the other API goo in many mainstream/mass-media sites, "initial app load time" is something users are probably pretty tolerant of, unless "load time" includes stuff beyond the page becoming interactive.
Re: The Performance Cost of Server Side Rendered React on Node.js
#45Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?
That's one use case.
The other is for performance/seo where the initial markup for the app is generated and served to the client as HTML, then the React app bootstraps on the client and takes over managing the DOM.
Re: The Performance Cost of Server Side Rendered React on Node.js
#46OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?
It's a real issue, my startup's react SSR times are ~5 seconds of blocking the node thread on my $40 droplet. It's about 50% react. Our pages are way more sophisticated than your average page with like a query and a form, though. There are many ways to make faster though, one of which is to simply configure your CDN properly.
5 seconds per request??
What on earth? Our entire app is React+Redux based, gathers a bunch of unique user data per-request from various apis and we still get ~40-120ms response times (and that's on CDN cache misses).
Hell, our Node server's connection timeout is 3 seconds and we only ever hit that due an APIs tanking or something.
Re: The Performance Cost of Server Side Rendered React on Node.js
#47OK from single core $10 VPS you will be able to serve 1,080,000 unique initial loads per hour and depending on your pattern of traffic say 15,000,000 in a day could you remind me what the issue is again?
Assuming that your actual use case is rendering one small HTML table, yes. It probably isn’t, though.
Re: The Performance Cost of Server Side Rendered React on Node.js
#48Earlier quoted context omitted.
Does anyone actually use vanilla JavaScript string literals for all their backend rendering?
There's the lit-html[1] project, which is still fairly new. It uses tagged template literals to render to the DOM, so on the server side it could fall back to vanilla string interpolation. [1]: https://github.com/PolymerLabs/lit-html
And hyperHTML [1] that preceded it and has near identical API.
Re: The Performance Cost of Server Side Rendered React on Node.js
#49Isn't the whole point of server-side rendered React to render it just once, when building the website, and then serve it as static HTML/JS/CSS assets using a static webserver?
How do you do that with dynamic content?
In my view the user-specific parts and frequently updating data should be rendered on the client side. The pre-rendered HTML should contain the less-frequently changing information that is important for SEO.
Re: The Performance Cost of Server Side Rendered React on Node.js
#50I'd like to see the results with php through node-phpcgi to render those pages. So we'd have gone full circle at last.