RSC made our site much faster
RSC made our site much faster
RSC made our site much faster
Engineering
Sep 20, 2023
Engineering
Sep 20, 2023
Engineering
Sep 20, 2023
Christian Mathiesen
Christian Mathiesen
Christian Mathiesen
If you're not already familiar, React Server Components allow you to split server and client rendering out between individual components, rather than having your entire app be one or the other. This means that on the server, you can securely call server-only APIs without leaking keys to the client. On the client, you can use browser APIs knowing that your code will only be run in the browser.
And for the optimization nerds (it's us, we're the optimization nerds) you can drop server-only dependencies from your client bundle, significantly reducing how much code you send down the pipe. All of this is only scratching the surface of RSC — you can read more about the benefits of RSC in Vercel's blog post Understanding React Server Components.
But let’s assume for the moment that you already know about RSC and you’re here to read a case study containing Significant Perf Gains. We have you covered there:
Experiment: productonboarding.com
Setup
We recently launched a free visual catalog of industry best-practices for product onboarding, which can be found on (you guessed it!) productonboarding.com. The project leverages the latest version of Next.js as well as React Server Components served through the new App Router. We use Frigade to power the email subscription flow at the top of the index page.
Methodology
To test the performance of using Frigade with RSC, we built both an RSC Version of the website and a non-RSC version that uses the Pages Router. We then deployed the two different websites to Vercel and measured performance using the Pingdom Speedtest as well as Google's PageSpeed Insights test.
Results
We saw a whopping 62% reduction in bundle size as well as as 63% improvement in Google's Speed Index on the RSC Version of the website. While we expected an improvement in the RSC version, we were surprised to see such a significant impact. While the served page size increased in the RSC version, it still got to the first contentful paint significantly faster than the client-side version, which had a smaller page size and a larger bundle.
Conclusion and what's next
Given the results of the experiment on our own code, we see demand for RSC-compatible libraries growing going forward. You really can’t argue with dropping more than half your bundle.
On a related note, the Frigade React SDK now works with React Server Components! Wild coincidence eh? If you're using Next.js 13, you can use @frigade/react 1.36.4 or higher with the App Router.
If you're not already familiar, React Server Components allow you to split server and client rendering out between individual components, rather than having your entire app be one or the other. This means that on the server, you can securely call server-only APIs without leaking keys to the client. On the client, you can use browser APIs knowing that your code will only be run in the browser.
And for the optimization nerds (it's us, we're the optimization nerds) you can drop server-only dependencies from your client bundle, significantly reducing how much code you send down the pipe. All of this is only scratching the surface of RSC — you can read more about the benefits of RSC in Vercel's blog post Understanding React Server Components.
But let’s assume for the moment that you already know about RSC and you’re here to read a case study containing Significant Perf Gains. We have you covered there:
Experiment: productonboarding.com
Setup
We recently launched a free visual catalog of industry best-practices for product onboarding, which can be found on (you guessed it!) productonboarding.com. The project leverages the latest version of Next.js as well as React Server Components served through the new App Router. We use Frigade to power the email subscription flow at the top of the index page.
Methodology
To test the performance of using Frigade with RSC, we built both an RSC Version of the website and a non-RSC version that uses the Pages Router. We then deployed the two different websites to Vercel and measured performance using the Pingdom Speedtest as well as Google's PageSpeed Insights test.
Results
We saw a whopping 62% reduction in bundle size as well as as 63% improvement in Google's Speed Index on the RSC Version of the website. While we expected an improvement in the RSC version, we were surprised to see such a significant impact. While the served page size increased in the RSC version, it still got to the first contentful paint significantly faster than the client-side version, which had a smaller page size and a larger bundle.
Conclusion and what's next
Given the results of the experiment on our own code, we see demand for RSC-compatible libraries growing going forward. You really can’t argue with dropping more than half your bundle.
On a related note, the Frigade React SDK now works with React Server Components! Wild coincidence eh? If you're using Next.js 13, you can use @frigade/react 1.36.4 or higher with the App Router.
If you're not already familiar, React Server Components allow you to split server and client rendering out between individual components, rather than having your entire app be one or the other. This means that on the server, you can securely call server-only APIs without leaking keys to the client. On the client, you can use browser APIs knowing that your code will only be run in the browser.
And for the optimization nerds (it's us, we're the optimization nerds) you can drop server-only dependencies from your client bundle, significantly reducing how much code you send down the pipe. All of this is only scratching the surface of RSC — you can read more about the benefits of RSC in Vercel's blog post Understanding React Server Components.
But let’s assume for the moment that you already know about RSC and you’re here to read a case study containing Significant Perf Gains. We have you covered there:
Experiment: productonboarding.com
Setup
We recently launched a free visual catalog of industry best-practices for product onboarding, which can be found on (you guessed it!) productonboarding.com. The project leverages the latest version of Next.js as well as React Server Components served through the new App Router. We use Frigade to power the email subscription flow at the top of the index page.
Methodology
To test the performance of using Frigade with RSC, we built both an RSC Version of the website and a non-RSC version that uses the Pages Router. We then deployed the two different websites to Vercel and measured performance using the Pingdom Speedtest as well as Google's PageSpeed Insights test.
Results
We saw a whopping 62% reduction in bundle size as well as as 63% improvement in Google's Speed Index on the RSC Version of the website. While we expected an improvement in the RSC version, we were surprised to see such a significant impact. While the served page size increased in the RSC version, it still got to the first contentful paint significantly faster than the client-side version, which had a smaller page size and a larger bundle.
Conclusion and what's next
Given the results of the experiment on our own code, we see demand for RSC-compatible libraries growing going forward. You really can’t argue with dropping more than half your bundle.
On a related note, the Frigade React SDK now works with React Server Components! Wild coincidence eh? If you're using Next.js 13, you can use @frigade/react 1.36.4 or higher with the App Router.