React Server Components made our site a lot faster
frigade.com
frigade.com
To test this out, I conducted an experiment where I built an RSC version and a traditional client-side React version of the same website and measured performance. We were able to improve our bundle size and speed by 62% and 63%, respectively. You can find the whole writeup here. https://frigade.com/blog/bundle-size-reduction-with-rsc-and-...
I actually enjoyed building with RSC more than I expected to, and it made for a better user experience since it rendered almost 3x faster than the client version.
Would love to hear any feedback and thoughts on our experiment. Have you started to use React Server Components yet, or no? Have you seen similar results?
It doesn't look like either of your tools measures overall performance for a site visit (as I characterize it), but maybe it doesn't matter in your case. What was your thinking in this regard?
I need to go lie down
I'm assuming Gen Z? You are aware that your index.html of your React app is also server-side rendered, right? And you are aware that all the API's that your SPA talks to are also server-side rendered, right?
As I read it, OP is just anticipating that reaction, acknowledging it upfront with a bit of levity.
I think the move React is making to embrace the server side is a great thing. It shows we pushed really hard in one direction, made great progress in building a simple and easy-to-grok front end JS library in doing so, but in the end found that the server _is_ the correct place for the majority of the processing to happen in most cases. The great thing with React Server Components is you don't have to change much about how you write react code, you can just define which specific components you need to render on the client side and boom, huge performance jump. Why is that a bad thing?
Then, hey, it turns out those idiot backend devs that were so looked down upon may actually have known what they were doing after all.
There's also the bit where RSC seems wonderful if all you know is react but seems very mediocre if you've any significant experience with any of a number of other backend stacks
I have only worked at more "traditional" companies so that likely influences my experience as well, it may be different at different kinds of companies.
"We made a UI framework that slows down web sites unnecessarily... but don't worry! We've now made a massive addition to the framework to mitigate the problem of our own creation! Isn't it wonderful?"
Feels somehow akin to standing in a hole and being given a shovel to dig your way out.
I’ve looked at Nashorn and then Graal to do this, but couldn’t find widely supported resources that work well and snap right in. Anyone in the same boat that has had success?
HTML templating works great, it's battle tested, typically still blows away RSC performance, and you get to keep all your mature domain logic and data layers while being able to deliver great UX with minimal client code
I want to be able to tell them "Hey, Green at 600ms will still give us an SEO boost over Green at 800ms, so we should do this," but I am having a hard time establishing whether that is actually true. Does anyone know for sure?
More broadly, prioritisation isn't about whether a piece of work will achieve its aim, it's about understanding which options are the best use of limited resources. For example, you may be able to say confidently that reducing CWV from 800ms to 600ms will increase your traffic from Google search by 5% but that's immaterial until it's compared against other options -- there's an opportunity cost associated with all work.
Personally, I would be surprised if reducing CWV from 800ms to 600ms is the best use of your resources, unless your business is one of the few that has a strong organic search strategy with organic search accounting for a meaningful volume of revenue -- nowadays, most companies find paid ads are much more effective.
As a first approximation, the difference between 600ms and 800ms will probably be similar to the difference between 800ms and 1000ms. You should be able to get a rough figure of what that difference is with 1 line of change to your code.
I feel like I am in the right place at the right time to be just so happening to be working on a better and more modern Wordpress :)
If client-side/server-side rendering with static and incremental loading, combined with dynamic markdown loading is your type of thing; please checkout my project and give me a star to follow.
If I have an API sever and then instead of calling those apis from client, I make all db calls on the server and then render the html. How much of processing that was done was spent on rendering html.
Also I wonder how react server components and serverside rendering go with localfirst software?
I love localfirst web apps, they seem kinda incompatible with serverside apps
This project is a marketing site, for which client-side rendering never made sense.
Only advice would be: don't follow these fads unless you a) are doing it to learn or b) can quantify tangible business value in the change. The worst reason to do it is because everyone else seems to be doing it*
*Unless literally everyone is doing it and the "old" thing becomes unsupported.
This has nothing to do with RSC, and @dang /moderators should probably change the headline.
"Moving from a client-side app to a server app (using React Server Components) made our site faster" is very unsurprising, not very interesting (what would be interesting is comparison from another server rendering technique), and wouldn't have made the HN homepage likely, but they've already cheesed their way here.
You clearly have familiarity with the technical landscape, perhaps more than most here! And maybe I’m projecting this part, but my hunch is that (like me) you follow the space closely? If I may offer some advice, for whatever it’s worth: there’s going to be a very long tail of people coming to this, or any similar, solution with less depth of knowledge and nuance, and it might be a more enjoyable reading experience to preemptively give them some grace on that.
If anything I'm helping people less experienced understand this. HN does this title clarification all the time for much less concrete things.
I'd ask you why you felt necessary to bring in the "weird" adjective when clearly you understand this area and exactly how the less informed may not understand those graphs and title - in this very thread many of people even seem totally confused that RSC = the only way to do server rendering = novel to React. If I can give you feedback as well, instead of trying to score a point and muddy waters, just write the improved version of what I'm saying if you feel capable of doing so.
Not trying to score anything, I just sincerely think your approach to the article and its discussion is unnecessarily combative.
> just write the improved version of what I'm saying if you feel capable of doing so.
I don’t agree with your perspective that there’s anything deceptive or untoward about the article—or its title—as presented. I don’t feel capable of rewriting that position. Cheers!
If you wish to engage substantively, do see the multiple confused people in this very thread that illustrate the point clearly. It's very hard to reconcile their confusion with your point that this is clear to the general audience.
Perhaps your very experience with the subject is a hindrance to seeing that. Cheers.
You seem to be taking personal offense to using React Server Components for this, which is odd to me.
Sure you can render to static markup without RSC but then you have to do a lot of work to mix server/interactive client components, RSC makes it a lot easier to achieve “server based apps”.
It’s not a deceptive headline at all.
Partial hydration is great but it’s a shame React is coupling it to a whole new routing model, component model, server rendering, and with such complex rules on use and inherent waterfalls as a side effect. There’s no reason to. You can get partial hydration any number of ways and avoid all the complexity.
If when you say "they could have moved to a server based app", you are implying that they could have done partial hydration easily some other way, that's a wild assumption. Until very recently partial hydration was not even on the table, as the community decided that downloading 10MB of JS for every website was fine, and not 'quite doable' for the majority of React apps; they are usually monolithic and built on top of frameworks that make it difficult. Not impossible (we were doing this back in 2016 with different tech), but very uncommon.
As I said above, this is exactly what RSC is solving for. It's not a new thing, but the first solution endorsed by React itself, and enabled them (and potentially all React apps) to gain SSR with partial hydration, reduce bundle sizes and actually improve load performance.
I'm not a big fan of any of this, just stating what it is. And I agree that it introduces monstrous complexity to an ecosystem that's already overflowing with it. Astro for example achieves this without introducing too many new concepts.
Maybe I was too strong worded, but the point stands that without making it really clear they are "skipping a generation" basically, it makes their comparison look extremely favorable, whereas RSC actually has a big overhead: it serializes all props and the entire tree that's not hydrated into an arbitrary serialization format that JS then needs to parse and hydrate. They actually are far from as zero-cost as other partial hydration methods. And if you had compared SSR vs RSC you'd see that the numbers don't actually improve so much.
So is it like 10/10 deceptive? No, but it's also a meme thats going around and not the first article to try and gain attention by conveniently leaving out of the title and most of the article that 80% of the gain they got was just going from client-only to server-rendered, and not actually RSC. I absolutely stand by it being deceptive, if only on a more annoying than actually harmful level. The graphs aren't comparing SSR to RSC, they're comparing the (comparatively much, much worse) client-only to RSC.
That's what the article is about, isn't it? The gain comes from going from client-only to server-rendered. They did this using RSC. You could also do it using handlebars and jQuery if it was 2010 (with probably 100x better performance).
> if you had compared SSR vs RSC you'd see that the numbers don't actually improve so much
From the article: We saw a whopping 62% reduction in bundle size as well as as 63% improvement in Google's Speed Index. You would not get those gains by simply enabling SSR in an existing app, as the bundle size will remain the same. Unless.. you use Astro or RSC to enable SSR with partial hydration. Which is what they did.
Likewise RSC is not nearly as free as other partial hydration methods. You send a full serialized copy of the tree and props over that has to be manually de serialized. This nullifies much of the benefit. Further, you still send the large (even larger now) copy of React. This is exactly why the comparison would be interesting to see, and why I brought up my concerns - it seems people are pretty under informed about this.
The article is about a mostly-static marketing page.