8 ms·

React Server Components made our site a lot faster

40 points by pancomplex 3y ago

pancomplex 3y ago
Hey HN! I wanted to share an experiment I ran that tests the performance of RSC vs traditional client-side React on one of our product websites (productonboarding.com). I know RSC is a bit of a controversial topic since server-side rendering used to be an ancient paradigm with the shift to modern JS frameworks. As such, I went into the experiment with a healthy dose of skepticism. 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-frigade 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?
- askonomm 3y ago
  > ancient paradigm 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?
  - eyelidlessness 3y ago
    It’s a frequent refrain on here, whenever some post talks about doing any server rendering in a JS context, that it was done before… even well before. It’s so frequent as to be cliche, and usually rather dismissive of any actual substance to the context of whatever’s in the post. As I read it, OP is just anticipating that reaction, acknowledging it upfront with a bit of levity.
- stiiv 3y ago
  A site visit might consist of more than a single page load, and (hopefully) includes some interactions. For some sites, "client-side + HTTP data as needed" strategy will have a longer time to first render, but might be much quicker once you introduce interaction. 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?
- afavour 3y ago
  > I know RSC is a bit of a controversial topic since server-side rendering used to be an ancient paradigm with the shift to modern JS frameworks I need to go lie down
flylikeabanana 3y ago
The contrast between text and background is way too low. I have "good" eyesight and strained to read the blog post
- pancomplex 3y ago
  Appreciate the feedback, we can likely tweak the colors a little!
- pancomplex 3y ago
  Update: we boosted the text contrast and we'll make some more visual improvements to the Blog throughout the day, too.
tunesmith 3y ago
Our site is dealing with a dynamic where our Core Web Vitals are already green, and thus our priority-setting folks don't see it as a priority to improve the score any further. 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?
- pancomplex 3y ago
  During the experiment we used Google's PageInsight which will give you a literal "Speed Index". Without RSC Google gave us a Speedindex of only 1.6 vs 0.6 with RSC, which seems to factor directly into the PageRank algorithm: https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search https://developers.google.com/search/blog/2018/01/using-page...
- iterminate 3y ago
  There's a temptation to get caught up on quantifiable scores when working on SEO because so much of it can't be quantified, everyone is mostly guessing what Google wants... however, scores are ultimately meaningless and you should be measuring the impact on your business metrics. For example, if your website is designed to generate sales, did reducing your CWV to 800ms improve revenue? SEO is a means to an end, you can spend thousands of human hours to rank #1 for a keyword but if it doesn't improve a metric that matters (e.g: your revenue) it's a complete waste of time. 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.
  - josephg 3y ago
random_kris 3y ago
I wonder how much overhead does the rendering or react on server add ? 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
- mrcwinn 3y ago
  In either case you have database calls (when calling an API, or when rendering from server). Adding network overhead (the subsequent request for data) is the last thing I'd want, if I could avoid it.
- toddmorey 3y ago
  You can choose on a component basis what you render server-side. This project is a marketing site, for which client-side rendering never made sense.
onemoresoop 3y ago
That sounds a lot like moving in circles:)
moribvndvs 3y ago
That’s great. What if I don’t want to write a whole new NodeJS backend just to support SSR, when the existing backend with all our APIs that we already wrote is a Spring Boot service? 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?
- falsandtru 3y ago
  There is SPA on Pjax. You can use an independent HTML and/or JSON server in any language to create SPA. https://github.com/falsandtru/pjax-api https://github.com/falsandtru/pjax-api https://falsandtru.github.io/pjax-api/docs/modes/ https://falsandtru.github.io/pjax-api/docs/modes/
- AprilArcus 3y ago
  I also maintain a JVM which we run some backend JS libraries on via custom Nashorn builds. It's slow and drinks memory. Setting up a façade in front of a pool of ScriptEngine objects mitigates some of the startup cost, but I super don't like the idea of running React for server rendering. I would suggest standing up a NodeJS rendering microservice instead; we'd do it if arcane deployment reasons didn't preclude the possibility.
- wild_egg 3y ago
  Pick up unpoly, HTMX, Hotwire, or some other hypermedia oriented library and have the Spring Boot server start rendering HTML instead of JSON 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
deleted 3y ago
[deleted]
Supply5411 3y ago
I must be getting older, because "everything old is new again" keeps coming to mind. 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.
- deleted 3y ago
  [deleted]
- DGCA 3y ago
  Just curious, what’s the fad you’re referring to. React? Client side rendering? Single page apps?
  - Supply5411 3y ago
    Server side rendering
nwienert 3y ago
Unbelievable, deceptive levels of clickbait at play - they moved from a client app to a server app, so of course the initial render is faster. 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.
- throwaway10965 3y ago
  I don't see the difference between their and your headline.
  - nwienert 3y ago
    Because they could have moved to a server based app not using RSC and seen similar gains, so the deception is they are trying to make it seem like RSC caused the gain (and riding on the back of a hyped new technology) whereas it's not really the case.
    - madjam002 3y ago
      But RSC is how you do server based apps with React, and they’re clearly sticking with React. 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.
      - nwienert 3y ago
        I think it’s less work to just use static content in places and avoid having to learn a whole new model of rendering, routing, data fetching and a lot of rules than it is to have a traditional ssr app that compiles a few static pieces of content.
    - ricardobeat 3y ago
afavour 3y ago
React Server Components drive me kind of crazy. "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.
- throwaway10965 3y ago
  It's more like "we made a UI framework that speeds up development and runtime of complex apps considerably, though it also slows down initial load of web sites... but don't worry, we have a fix".
  - afavour 3y ago
    Development? Yes. Runtime? Highly debatable. At a bare minimum there are other frameworks with a significantly better runtime performance story than React.
hoofhearted 3y ago
This space is evolving so fast, and I love it! 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. https://github.com/elegantframework/elegant-cli https://github.com/elegantframework/elegant-cli
willio58 3y ago
Wow there's a lot of negative comments here on such a simple post along the lines of "Hey we adopted this new version of this library and it boosted our site performance x%". 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?
- wild_egg 3y ago
  It's not that RSC is a bad thing, there's just a lot of animosity built up from years of react developers shitting on the concept of processing on servers and antagonizing the developers who work in that space. 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
  - fsociety 3y ago
    I have yet to meet a frontend dev who called a backend dev an idiot. I have met plenty of backend devs who have indirectly called frontend devs idiots.
    - willio58 3y ago
      I have to agree on this. But also anyone who calls anyone else an "idiot" for how they code is doing it wrong™. We can learn from what eachother thrive in. For backend, it's usually data structures, databases, performance, etc. while on the frontend it's creating visually appealing UIs that feel good to interact with and both of those sides of web dev act to bring people into what we create time and time again. So when backend devs get mad when frontend devs say "Hey, maybe backend isn't so bad after all", that feels backwards.

40 points by pancomplex 3y ago

Hey HN! I wanted to share an experiment I ran that tests the performance of RSC vs traditional client-side React on one of our product websites (productonboarding.com). I know RSC is a bit of a controversial topic since server-side rendering used to be an ancient paradigm with the shift to modern JS frameworks. As such, I went into the experiment with a healthy dose of skepticism. 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-frigade 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?

askonomm 3y ago
> ancient paradigm 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?
- eyelidlessness 3y ago
  It’s a frequent refrain on here, whenever some post talks about doing any server rendering in a JS context, that it was done before… even well before. It’s so frequent as to be cliche, and usually rather dismissive of any actual substance to the context of whatever’s in the post. As I read it, OP is just anticipating that reaction, acknowledging it upfront with a bit of levity.
stiiv 3y ago
A site visit might consist of more than a single page load, and (hopefully) includes some interactions. For some sites, "client-side + HTTP data as needed" strategy will have a longer time to first render, but might be much quicker once you introduce interaction. 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?
afavour 3y ago
> I know RSC is a bit of a controversial topic since server-side rendering used to be an ancient paradigm with the shift to modern JS frameworks I need to go lie down

flylikeabanana 3y ago

The contrast between text and background is way too low. I have "good" eyesight and strained to read the blog post

pancomplex 3y ago
Appreciate the feedback, we can likely tweak the colors a little!
pancomplex 3y ago
Update: we boosted the text contrast and we'll make some more visual improvements to the Blog throughout the day, too.

tunesmith 3y ago

Our site is dealing with a dynamic where our Core Web Vitals are already green, and thus our priority-setting folks don't see it as a priority to improve the score any further. 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?

pancomplex 3y ago
During the experiment we used Google's PageInsight which will give you a literal "Speed Index". Without RSC Google gave us a Speedindex of only 1.6 vs 0.6 with RSC, which seems to factor directly into the PageRank algorithm: https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search https://developers.google.com/search/blog/2018/01/using-page...
iterminate 3y ago
There's a temptation to get caught up on quantifiable scores when working on SEO because so much of it can't be quantified, everyone is mostly guessing what Google wants... however, scores are ultimately meaningless and you should be measuring the impact on your business metrics. For example, if your website is designed to generate sales, did reducing your CWV to 800ms improve revenue? SEO is a means to an end, you can spend thousands of human hours to rank #1 for a keyword but if it doesn't improve a metric that matters (e.g: your revenue) it's a complete waste of time. 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.
- josephg 3y ago

random_kris 3y ago

I wonder how much overhead does the rendering or react on server add ? 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

mrcwinn 3y ago
In either case you have database calls (when calling an API, or when rendering from server). Adding network overhead (the subsequent request for data) is the last thing I'd want, if I could avoid it.
toddmorey 3y ago
You can choose on a component basis what you render server-side. This project is a marketing site, for which client-side rendering never made sense.

onemoresoop 3y ago

That sounds a lot like moving in circles:)

moribvndvs 3y ago

That’s great. What if I don’t want to write a whole new NodeJS backend just to support SSR, when the existing backend with all our APIs that we already wrote is a Spring Boot service? 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?

falsandtru 3y ago
There is SPA on Pjax. You can use an independent HTML and/or JSON server in any language to create SPA. https://github.com/falsandtru/pjax-api https://github.com/falsandtru/pjax-api https://falsandtru.github.io/pjax-api/docs/modes/ https://falsandtru.github.io/pjax-api/docs/modes/
AprilArcus 3y ago
I also maintain a JVM which we run some backend JS libraries on via custom Nashorn builds. It's slow and drinks memory. Setting up a façade in front of a pool of ScriptEngine objects mitigates some of the startup cost, but I super don't like the idea of running React for server rendering. I would suggest standing up a NodeJS rendering microservice instead; we'd do it if arcane deployment reasons didn't preclude the possibility.
wild_egg 3y ago
Pick up unpoly, HTMX, Hotwire, or some other hypermedia oriented library and have the Spring Boot server start rendering HTML instead of JSON 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

deleted 3y ago

[deleted]

Supply5411 3y ago

I must be getting older, because "everything old is new again" keeps coming to mind. 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.

deleted 3y ago
[deleted]
DGCA 3y ago
Just curious, what’s the fad you’re referring to. React? Client side rendering? Single page apps?
- Supply5411 3y ago
  Server side rendering

nwienert 3y ago

Unbelievable, deceptive levels of clickbait at play - they moved from a client app to a server app, so of course the initial render is faster. 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.

throwaway10965 3y ago
I don't see the difference between their and your headline.
- nwienert 3y ago
  Because they could have moved to a server based app not using RSC and seen similar gains, so the deception is they are trying to make it seem like RSC caused the gain (and riding on the back of a hyped new technology) whereas it's not really the case.
  - madjam002 3y ago
    But RSC is how you do server based apps with React, and they’re clearly sticking with React. 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.
    - nwienert 3y ago
      I think it’s less work to just use static content in places and avoid having to learn a whole new model of rendering, routing, data fetching and a lot of rules than it is to have a traditional ssr app that compiles a few static pieces of content.
  - ricardobeat 3y ago

afavour 3y ago

React Server Components drive me kind of crazy. "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.

throwaway10965 3y ago
It's more like "we made a UI framework that speeds up development and runtime of complex apps considerably, though it also slows down initial load of web sites... but don't worry, we have a fix".
- afavour 3y ago
  Development? Yes. Runtime? Highly debatable. At a bare minimum there are other frameworks with a significantly better runtime performance story than React.

hoofhearted 3y ago

This space is evolving so fast, and I love it! 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. https://github.com/elegantframework/elegant-cli https://github.com/elegantframework/elegant-cli

willio58 3y ago

Wow there's a lot of negative comments here on such a simple post along the lines of "Hey we adopted this new version of this library and it boosted our site performance x%". 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?

wild_egg 3y ago
It's not that RSC is a bad thing, there's just a lot of animosity built up from years of react developers shitting on the concept of processing on servers and antagonizing the developers who work in that space. 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
- fsociety 3y ago
  I have yet to meet a frontend dev who called a backend dev an idiot. I have met plenty of backend devs who have indirectly called frontend devs idiots.
  - willio58 3y ago
    I have to agree on this. But also anyone who calls anyone else an "idiot" for how they code is doing it wrong™. We can learn from what eachother thrive in. For backend, it's usually data structures, databases, performance, etc. while on the frontend it's creating visually appealing UIs that feel good to interact with and both of those sides of web dev act to bring people into what we create time and time again. So when backend devs get mad when frontend devs say "Hey, maybe backend isn't so bad after all", that feels backwards.