Live data from Hacker News

React Server Components made our site a lot faster

frigade.com

1–10 of 62 posts

Re: React Server Components made our site a lot faster

#2
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-...

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?

Re: React Server Components made our site a lot faster

#4
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?

Re: React Server Components made our site a lot faster

#6

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?

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...

Re: React Server Components made our site a lot faster

#7
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

Re: React Server Components made our site a lot faster

#8

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 incompat…

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.

Re: React Server Components made our site a lot faster

#10

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?

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.

Post reply on HN