{"id":581,"date":"2024-05-09T13:00:00","date_gmt":"2024-05-09T13:00:00","guid":{"rendered":"https:\/\/francecourier.com\/?p=581"},"modified":"2025-06-20T10:51:43","modified_gmt":"2025-06-20T10:51:43","slug":"the-forensics-of-react-server-components-rscs","status":"publish","type":"post","link":"https:\/\/francecourier.com\/index.php\/2024\/05\/09\/the-forensics-of-react-server-components-rscs\/","title":{"rendered":"The Forensics Of React Server Components (RSCs)"},"content":{"rendered":"<p>              <title>The Forensics Of React Server Components (RSCs)<\/title><\/p>\n<article>\n<header>\n<h1>The Forensics Of React Server Components (RSCs)<\/h1>\n<address>Lazar Nikolov<\/address>\n<p>                  2024-05-09T13:00:00+00:00<br \/>\n                  2025-06-20T10:32:35+00:00<br \/>\n                <\/header>\n<p>This article is sponsored by <b>Sentry.io<\/b><\/p>\n<p>In this article, we\u2019re going to look deeply at React Server Components (RSCs). They are the latest innovation in React\u2019s ecosystem, leveraging both server-side and client-side rendering as well as <a href=\"https:\/\/en.wikipedia.org\/wiki\/Chunked_transfer_encoding\">streaming HTML<\/a> to deliver content as fast as possible.<\/p>\n<p>We will get really nerdy to get a full understanding of how RSCs fit into the React picture, the level of control they offer over the rendering lifecycle of components, and what page loads look like with RSCs in place.<\/p>\n<p>But before we dive into all of that, I think it\u2019s worth looking back at how React has rendered websites up until this point to set the context for why we need RSCs in the first place.<\/p>\n<h2 id=\"the-early-days-react-client-side-rendering\">The Early Days: React Client-Side Rendering<\/h2>\n<p>The first React apps were rendered on the client side, i.e., in the browser. As developers, we wrote apps with JavaScript classes as components and packaged everything up using bundlers, like Webpack, in a nicely compiled and tree-shaken heap of code ready to ship in a production environment.<\/p>\n<p>The HTML that returned from the server contained a few things, including:<\/p>\n<ul>\n<li>An HTML document with metadata in the <code><\/code> and a blank <code>\n<div><\/div>\n<p><\/code> in the <code><\/code> used as a hook to inject the app into the DOM;<\/li>\n<li>JavaScript resources containing React\u2019s core code and the actual code for the web app, which would generate the user interface and populate the app inside of the empty <code>\n<div><\/div>\n<p><\/code>.<\/li>\n<\/ul>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/1-client-side-rendering-process.jpg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"566\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Diagram of the client-side rendering process of a React app, starting with a blank loading page in the browser followed by a series of processes connected to CDNs and APIs to produce content on the loading page.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/1-client-side-rendering-process.jpg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 1. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/1-client-side-rendering-process.jpg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>A web app under this process is only fully interactive once JavaScript has fully completed its operations. You can probably already see the tension here that comes with an <strong>improved developer experience (DX) that negatively impacts the user experience (UX)<\/strong>.<\/p>\n<p>The truth is that there were (and are) pros and cons to CSR in React. Looking at the positives, web applications delivered <strong>smooth, quick transitions<\/strong> that reduced the overall time it took to load a page, thanks to reactive components that update with user interactions without triggering page refreshes. CSR lightens the server load and allows us to serve assets from speedy content delivery networks (CDNs) capable of delivering content to users from a server location geographically closer to the user for even more optimized page loads.<\/p>\n<p>There are also not-so-great consequences that come with CSR, most notably perhaps that components could fetch data independently, leading to <a href=\"https:\/\/blog.sentry.io\/fetch-waterfall-in-react\/\"><strong>waterfall network requests<\/strong><\/a> that dramatically slow things down. This may sound like a minor nuisance on the UX side of things, but the damage can actually be quite large on a human level. Eric Bailey\u2019s \u201c<a href=\"https:\/\/ericwbailey.design\/published\/modern-health-frameworks-performance-and-harm\/\">Modern Health, frameworks, performance, and harm<\/a>\u201d should be a cautionary tale for all CSR work.<\/p>\n<p>Other negative CSR consequences are not quite as severe but still lead to damage. For example, it used to be that an HTML document containing nothing but metadata and an empty <code><\/p>\n<div><\/div>\n<p><\/code> was illegible to search engine crawlers that never get the fully-rendered experience. While that\u2019s solved today, the SEO hit at the time was an anchor on company sites that rely on search engine traffic to generate revenue.<\/p>\n<h2 id=\"the-shift-server-side-rendering-ssr\">The Shift: Server-Side Rendering (SSR)<\/h2>\n<p>Something needed to change. CSR presented developers with a powerful new approach for constructing speedy, interactive interfaces, but users everywhere were inundated with blank screens and loading indicators to get there. The solution was to move the rendering experience from the <strong>client<\/strong> to the <strong>server<\/strong>. I know it sounds funny that we needed to improve something by going back to the way it was before.<\/p>\n<p>So, yes, React gained server-side rendering (SSR) capabilities. At one point, SSR was such a topic in the React community that <a href=\"https:\/\/sentry.io\/resources\/moving-to-server-side-rendering\/\">it had a moment<\/a> in the spotlight. The move to SSR brought significant changes to app development, specifically in how it influenced React behavior and how content could be delivered by way of servers instead of browsers.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/2-diagram-server-side-rendering-process.jpg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"600\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Diagram of the server-side rendering process of a React app, starting with a blank loading page in the browser followed by a screen of un-interactive content, then a fully interactive page of content.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/2-diagram-server-side-rendering-process.jpg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 2. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/2-diagram-server-side-rendering-process.jpg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<h3 id=\"addressing-csr-limitations\">Addressing CSR Limitations<\/h3>\n<p>Instead of sending a blank HTML document with SSR, we rendered the initial HTML on the server and sent it to the browser. The browser was able to immediately start displaying the content without needing to show a loading indicator. This significantly improves the <a href=\"https:\/\/docs.sentry.io\/product\/performance\/web-vitals\/web-vitals-concepts\/#first-contentful-paint-fcp\">First Contentful Paint (FCP) performance metric in Web Vitals<\/a>.<\/p>\n<p>Server-side rendering also fixed the SEO issues that came with CSR. Since the crawlers received the content of our websites directly, they were then able to index it right away. The data fetching that happens initially also takes place on the server, which is a plus because it\u2019s closer to the data source and can eliminate fetch waterfalls <a href=\"https:\/\/blog.sentry.io\/fetch-waterfall-in-react\/#fetch-data-on-server-to-avoid-a-fetch-waterfall\"><em>if done properly<\/em><\/a>.<\/p>\n<h3 id=\"hydration\">Hydration<\/h3>\n<p>SSR has its own complexities. For React to make the static HTML received from the server interactive, it needs to <strong>hydrate<\/strong> it. Hydration is the process that happens when React reconstructs its Virtual Document Object Model (DOM) on the client side based on what was in the DOM of the initial HTML.<\/p>\n<blockquote><p><strong>Note<\/strong>: React maintains its own <a href=\"https:\/\/legacy.reactjs.org\/docs\/faq-internals.html\">Virtual DOM<\/a> because it\u2019s faster to figure out updates on it instead of the actual DOM. It synchronizes the actual DOM with the Virtual DOM when it needs to update the UI but performs the diffing algorithm on the Virtual DOM.<\/p><\/blockquote>\n<p>We now have two flavors of Reacts:<\/p>\n<ol>\n<li><strong>A server-side flavor<\/strong> that knows how to render static HTML from our component tree,<\/li>\n<li><strong>A client-side flavor<\/strong> that knows how to make the page interactive.<\/li>\n<\/ol>\n<p>We\u2019re still shipping React and code for the app to the browser because \u2014 in order to hydrate the initial HTML \u2014 React needs the same components on the client side that were used on the server. During hydration, <a href=\"https:\/\/css-tricks.com\/how-react-reconciliation-works\/\">React performs a process called<\/a> <a href=\"https:\/\/css-tricks.com\/how-react-reconciliation-works\/\"><em>reconciliation<\/em><\/a> in which it compares the server-rendered DOM with the client-rendered DOM and tries to identify differences between the two. If there are differences between the two DOMs, React attempts to fix them by rehydrating the component tree and updating the component hierarchy to match the server-rendered structure. And if there are <em>still<\/em> inconsistencies that cannot be resolved, React will throw errors to indicate the problem. This problem is commonly known as a <em>hydration error<\/em>.<\/p>\n<h3 id=\"ssr-drawbacks\">SSR Drawbacks<\/h3>\n<p>SSR is not a silver bullet solution that addresses CSR limitations. SSR comes with its own drawbacks. Since we moved the initial HTML rendering and data fetching to the server, those servers are now experiencing a much greater load than when we loaded everything on the client.<\/p>\n<p>Remember when I mentioned that SSR generally improves the FCP performance metric? That may be true, but the <a href=\"https:\/\/docs.sentry.io\/product\/performance\/web-vitals\/web-vitals-concepts\/#time-to-first-byte-ttfb\">Time to First Byte (TTFB) performance metric<\/a> took a negative hit with SSR. The browser literally has to wait for the server to fetch the data it needs, generate the initial HTML, and send the first byte. And while TTFB is not a Core Web Vital metric in itself, it influences the metrics. A negative TTFB leads to negative Core Web Vitals metrics.<\/p>\n<p>Another drawback of SSR is that the entire page is unresponsive until client-side React has finished hydrating it. Interactive elements cannot listen and \u201creact\u201d to user interactions before React hydrates them, i.e., React attaches the intended event listeners to them. The hydration process is typically fast, but the internet connection and hardware capabilities of the device in use can slow down rendering by a noticeable amount.<\/p>\n<h2 id=\"the-present-a-hybrid-approach\">The Present: A Hybrid Approach<\/h2>\n<p>So far, we have covered two different flavors of React rendering: CSR and SSR. While the two were attempts to improve one another, we now get the best of both worlds, so to speak, as SSR has branched into three additional React flavors that offer a hybrid approach in hopes of reducing the limitations that come with CSR and SSR.<\/p>\n<p>We\u2019ll look at the first two \u2014 <strong>static site generation<\/strong> and <strong>incremental static regeneration<\/strong> \u2014 before jumping into an entire discussion on React Server Components, the third flavor.<\/p>\n<h3 id=\"static-site-generation-ssg\">Static Site Generation (SSG)<\/h3>\n<p>Instead of regenerating the same HTML code on every request, we came up with SSG. This React flavor compiles and builds the entire app at build time, generating static (as in vanilla HTML and CSS) files that are, in turn, hosted on a speedy CDN.<\/p>\n<p>As you might suspect, this hybrid approach to rendering is a nice fit for smaller projects where the content doesn\u2019t change much, like a marketing site or a personal blog, as opposed to larger projects where content may change with user interactions, like an e-commerce site.<\/p>\n<p>SSG reduces the burden on the server while improving performance metrics related to TTFB because the server no longer has to perform heavy, expensive tasks for re-rendering the page.<\/p>\n<h3 id=\"incremental-static-regeneration-isr\">Incremental Static Regeneration (ISR)<\/h3>\n<p>One SSG drawback is having to rebuild all of the app\u2019s code when a content change is needed. The content is set in stone \u2014 being static and all \u2014 and there\u2019s no way to change just one part of it without rebuilding the whole thing.<\/p>\n<p>The Next.js team created the second hybrid flavor of React that addresses the drawback of complete SSG rebuilds: <strong>incremental static regeneration (ISR)<\/strong>. The name says a lot about the approach in that ISR only rebuilds what\u2019s needed instead of the entire thing. We generate the \u201cinitial version\u201d of the page statically during build time but are also able to rebuild any page containing stale data <em>after<\/em> a user lands on it (i.e., the server request triggers the data check).<\/p>\n<p>From that point on, the server will serve new versions of that page statically in increments when needed. That makes ISR a hybrid approach that is neatly positioned between SSG and traditional SSR.<\/p>\n<p>At the same time, ISR does not address the \u201cstale content\u201d symptom, where users may visit a page before it has finished being generated. Unlike SSG, ISR needs an actual server to regenerate individual pages in response to a user\u2019s browser making a server request. That means we lose the valuable ability to deploy ISR-based apps on a CDN for optimized asset delivery.<\/p>\n<h2 id=\"the-future-react-server-components\">The Future: React Server Components<\/h2>\n<p>Up until this point, we\u2019ve juggled between CSR, SSR, SSG, and ISR approaches, where all make some sort of trade-off, negatively affecting performance, development complexity, and user experience. Newly introduced <a href=\"https:\/\/nextjs.org\/docs\/app\/building-your-application\/rendering\/server-components\">React Server Components<\/a> (RSC) aim to address most of these drawbacks by allowing us \u2014 the developer \u2014 to <strong>choose the right rendering strategy for each individual React component<\/strong>.<\/p>\n<p>RSCs can significantly reduce the amount of JavaScript shipped to the client since we can selectively decide which ones to serve statically on the server and which render on the client side. There\u2019s a lot more control and flexibility for striking the right balance for your particular project.<\/p>\n<blockquote><p><strong>Note:<\/strong> It\u2019s important to keep in mind that as we adopt more advanced architectures, like RSCs, monitoring solutions become invaluable. Sentry offers robust <a href=\"https:\/\/docs.sentry.io\/product\/performance\/\">performance monitoring<\/a> and error-tracking capabilities that help you keep an eye on the real-world performance of your RSC-powered application. Sentry also helps you gain insights into how your releases are performing and how stable they are, which is yet another crucial feature to have while migrating your existing applications to RSCs. Implementing Sentry in an RSC-enabled framework like <a href=\"https:\/\/sentry.io\/for\/nextjs\/\">Next.js<\/a> is as easy as running a single terminal command.<\/p><\/blockquote>\n<p>But what exactly <em>is<\/em> an RSC? Let\u2019s pick one apart to see how it works under the hood.<\/p>\n<h2 id=\"the-anatomy-of-react-server-components\">The Anatomy of React Server Components<\/h2>\n<p>This new approach introduces two types of rendering components: <strong>Server Components<\/strong> and <strong>Client Components<\/strong>. The differences between these two are not <em>how<\/em> they function but <em>where<\/em> they execute and the environments they\u2019re designed for. At the time of this writing, the only way to use RSCs is through React frameworks. And at the moment, there are only three frameworks that support them: <a href=\"https:\/\/nextjs.org\/docs\/app\/building-your-application\/rendering\/server-components\">Next.js<\/a>, <a href=\"https:\/\/www.gatsbyjs.com\/docs\/conceptual\/partial-hydration\/\">Gatsby<\/a>, and <a href=\"https:\/\/redwoodjs.com\/blog\/rsc-now-in-redwoodjs\">RedwoodJS<\/a>.<\/p>\n<figure class=\"\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/3-wire-diagram-server-client-components.jpg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"763\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Wire diagram showing connected server components and client components represented as gray and blue dots, respectively.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/3-wire-diagram-server-client-components.jpg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 3: Example of an architecture consisting of Server Components and Client Components. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/3-wire-diagram-server-client-components.jpg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<h3 id=\"server-components\">Server Components<\/h3>\n<p>Server Components are designed to be executed on the server, and their code is never shipped to the browser. The HTML output and any props they might be accepting are the only pieces that are served. This approach has multiple performance benefits and user experience enhancements:<\/p>\n<ul>\n<li><strong>Server Components allow for large dependencies to remain on the server side.<\/strong><br \/>\nImagine using a large library for a component. If you\u2019re executing the component on the client side, it means that you\u2019re also shipping the full library to the browser. With Server Components, you\u2019re only taking the static HTML output and avoiding having to ship any JavaScript to the browser. Server Components are truly static, and they remove the whole hydration step.<\/li>\n<li><strong>Server Components are located much closer to the data sources \u2014 e.g., databases or file systems \u2014 they need to generate code.<\/strong><br \/>\nThey also leverage the server\u2019s computational power to speed up compute-intensive rendering tasks and send only the generated results back to the client. They are also generated in a single pass, which <a href=\"https:\/\/blog.sentry.io\/fetch-waterfall-in-react\/#fetch-data-on-server-to-avoid-a-fetch-waterfall\">avoids request waterfalls and HTTP round trips<\/a>.<\/li>\n<li><strong>Server Components safely keep sensitive data and logic away from the browser.<\/strong><br \/>\nThat\u2019s thanks to the fact that personal tokens and API keys are executed on a secure server rather than the client.<\/li>\n<li><strong>The rendering results can be cached and reused between subsequent requests and even across different sessions.<\/strong><br \/>\nThis significantly reduces rendering time, as well as the overall amount of data that is fetched for each request.<\/li>\n<\/ul>\n<p>This architecture also makes use of <strong>HTML streaming<\/strong>, which means the server defers generating HTML for specific components and instead renders a fallback element in their place while it works on sending back the generated HTML. Streaming Server Components wrap components in <a href=\"https:\/\/react.dev\/reference\/react\/Suspense\"><code><\/code><\/a> tags that provide a fallback value. The implementing framework uses the fallback initially but streams the newly generated content when it\u2018s ready. We\u2019ll talk more about streaming, but let\u2019s first look at Client Components and compare them to Server Components.<\/p>\n<h3 id=\"client-components\">Client Components<\/h3>\n<p>Client Components are the components we already know and love. They\u2019re executed on the client side. Because of this, Client Components are capable of handling user interactions and have access to the browser APIs like <code>localStorage<\/code> and geolocation.<\/p>\n<p>The term \u201cClient Component\u201d doesn\u2019t describe anything new; they merely are given the label to help distinguish the \u201cold\u201d CSR components from Server Components. Client Components are defined by a <a href=\"https:\/\/react.dev\/reference\/react\/use-server\"><code>\"use client\"<\/code><\/a> directive at the top of their files.<\/p>\n<pre><code class=\"language-javascript\">\"use client\"\nexport default function LikeButton() {\n  const likePost = () =&gt; {\n    \/\/ ...\n  }\n  return (\n    <button>Like<\/button>\n  )\n}\n<\/code><\/pre>\n<p>In Next.js, all components are Server Components by default. That\u2019s why we need to explicitly define our Client Components with <code>\"use client\"<\/code>. There\u2019s also a <code>\"use server\"<\/code> directive, but it\u2019s used for Server Actions (which are RPC-like actions that invoked from the client, but executed on the server). You don\u2019t use it to define your Server Components.<\/p>\n<p>You might (rightfully) assume that Client Components are only rendered on the client, but Next.js renders Client Components on the server to generate the initial HTML. As a result, browsers can immediately start rendering them and then perform hydration later.<\/p>\n<h3 id=\"the-relationship-between-server-components-and-client-components\">The Relationship Between Server Components and Client Components<\/h3>\n<p>Client Components can only <em>explicitly<\/em> import other Client Components. In other words, we\u2019re unable to import a Server Component into a Client Component because of re-rendering issues. But we can have Server Components in a Client Component\u2019s subtree \u2014 only passed through the <code>children<\/code> prop. Since Client Components live in the browser and they handle user interactions or define their own state, they get to re-render often. When a Client Component re-renders, so will its subtree. But if its subtree contains Server Components, how would they re-render? They don\u2019t live on the client side. That\u2019s why the React team put that limitation in place.<\/p>\n<p>But hold on! We actually <em>can<\/em> import Server Components into Client Components. It\u2019s just not a direct one-to-one relationship because the Server Component will be converted into a Client Component. If you\u2019re using server APIs that you can\u2019t use in the browser, you\u2019ll get an error; if not \u2014 you\u2019ll have a Server Component whose code gets \u201cleaked\u201d to the browser.<\/p>\n<p>This is an incredibly important nuance to keep in mind as you work with RSCs.<\/p>\n<h2 id=\"the-rendering-lifecycle\">The Rendering Lifecycle<\/h2>\n<p>Here\u2019s the order of operations that Next.js takes to stream contents:<\/p>\n<ol>\n<li>The app router matches the page\u2019s URL to a Server Component, builds the component tree, and instructs the server-side React to render that Server Component and all of its children components.<\/li>\n<li>During render, React generates an \u201cRSC Payload\u201d. The RSC Payload informs Next.js about the page and what to expect in return, as well as what to fall back to during a <code><\/code>.<\/li>\n<li>If React encounters a suspended component, it pauses rendering that subtree and uses the suspended component\u2019s fallback value.<\/li>\n<li>When React loops through the last static component, Next.js prepares the generated HTML and the RSC Payload before streaming it back to the client through one or multiple chunks.<\/li>\n<li>The client-side React then uses the instructions it has for the RSC Payload and client-side components to render the UI. It also hydrates each Client Component as they load.<\/li>\n<li>The server streams in the suspended Server Components as they become available as an RSC Payload. Children of Client Components are also hydrated at this time if the suspended component contains any.<\/li>\n<\/ol>\n<p>We will look at the RSC rendering lifecycle from the browser\u2019s perspective momentarily. For now, the following figure illustrates the outlined steps we covered.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/4-wire-diagram-rsc-rendering-lifecycle.jpg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"489\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Wire diagram of the RSC rendering lifecycle going from a blank page to a page shell to a complete page.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/4-wire-diagram-rsc-rendering-lifecycle.jpg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 4: Diagram of the RSC Rendering Lifecycle. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/4-wire-diagram-rsc-rendering-lifecycle.jpg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>We\u2019ll see this operation flow from the browser\u2019s perspective in just a bit.<\/p>\n<h2 id=\"rsc-payload\">RSC Payload<\/h2>\n<p>The RSC payload is a special data format that the server generates as it renders the component tree, and it includes the following:<\/p>\n<ul>\n<li>The rendered HTML,<\/li>\n<li>Placeholders where the Client Components should be rendered,<\/li>\n<li>References to the Client Components\u2019 JavaScript files,<\/li>\n<li>Instructions on which JavaScript files it should invoke,<\/li>\n<li>Any props passed from a Server Component to a Client Component.<\/li>\n<\/ul>\n<p>There\u2019s no reason to worry much about the RSC payload, but it\u2019s worth understanding what exactly the RSC payload contains. Let\u2019s examine an example (truncated for brevity) from a <a href=\"https:\/\/github.com\/nikolovlazar\/rsc-forensics\">demo app I created<\/a>:<\/p>\n<div class=\"break-out\">\n<pre><code class=\"language-javascript\">1:HL[\"\/_next\/static\/media\/c9a5bc6a7c948fb0-s.p.woff2\",\"font\",{\"crossOrigin\":\"\",\"type\":\"font\/woff2\"}]\n2:HL[\"\/_next\/static\/css\/app\/layout.css?v=1711137019097\",\"style\"]\n0:\"$L3\"\n4:HL[\"\/_next\/static\/css\/app\/page.css?v=1711137019097\",\"style\"]\n5:I[\"(app-pages-browser)\/.\/node_modules\/next\/dist\/client\/components\/app-router.js\",[\"app-pages-internals\",\"static\/chunks\/app-pages-internals.js\"],\"\"]\n8:\"$Sreact.suspense\"\na:I[\"(app-pages-browser)\/.\/node_modules\/next\/dist\/client\/components\/layout-router.js\",[\"app-pages-internals\",\"static\/chunks\/app-pages-internals.js\"],\"\"]\nb:I[\"(app-pages-browser)\/.\/node_modules\/next\/dist\/client\/components\/render-from-template-context.js\",[\"app-pages-internals\",\"static\/chunks\/app-pages-internals.js\"],\"\"]\nd:I[\"(app-pages-browser)\/.\/src\/app\/global-error.jsx\",[\"app\/global-error\",\"static\/chunks\/app\/global-error.js\"],\"\"]\nf:I[\"(app-pages-browser)\/.\/src\/components\/clearCart.js\",[\"app\/page\",\"static\/chunks\/app\/page.js\"],\"ClearCart\"]\n7:[\"$\",\"main\",null,{\"className\":\"page_main__GlU4n\",\"children\":[[\"$\",\"$Lf\",null,{}],[\"$\",\"$8\",null,{\"fallback\":[\"$\",\"p\",null,{\"children\":\"\ud83c\udf00 loading products...\"}],\"children\":\"$L10\"}]]}]\nc:[[\"$\",\"meta\",\"0\",{\"name\":\"viewport\",\"content\":\"width=device-width, initial-scale=1\"}]...\n9:[\"$\",\"p\",null,{\"children\":[\"\ud83d\udecd\ufe0f \",3]}]\n11:I[\"(app-pages-browser)\/.\/src\/components\/addToCart.js\",[\"app\/page\",\"static\/chunks\/app\/page.js\"],\"AddToCart\"]\n10:[\"$\",\"ul\",null,{\"children\":[[\"$\",\"li\",\"1\",{\"children\":[\"Gloves\",\" - $\",20,[\"$...\n<\/code><\/pre>\n<\/div>\n<p>To find this code in the demo app, open your browser\u2019s developer tools at the Elements tab and look at the <code><\/code> tags at the bottom of the page. They\u2019ll contain lines like:<\/p>\n<pre><code class=\"language-javascript\">self.__next_f.push([1,\"PAYLOAD_STRING_HERE\"]).\n<\/code><\/pre>\n<p>Every line from the snippet above is an individual RSC payload. You can see that each line starts with a number or a letter, followed by a colon, and then an array that\u2019s sometimes prefixed with letters. We won\u2019t get into too deep in detail as to what they mean, but in general:<\/p>\n<ul>\n<li><strong><code>HL<\/code> payloads<\/strong> are called \u201chints\u201d and link to specific resources like CSS and fonts.<\/li>\n<li><strong><code>I<\/code> payloads<\/strong> are called \u201cmodules,\u201d and they invoke specific scripts. This is how Client Components are being loaded as well. If the Client Component is part of the main bundle, it\u2019ll execute. If it\u2019s not (meaning it\u2019s lazy-loaded), a fetcher script is added to the main bundle that fetches the component\u2019s CSS and JavaScript files when it needs to be rendered. There\u2019s going to be an <code>I<\/code> payload sent from the server that invokes the fetcher script when needed.<\/li>\n<li><strong><code>\"$\"<\/code> payloads<\/strong> are DOM definitions generated for a certain Server Component. They are usually accompanied by actual static HTML streamed from the server. That\u2019s what happens when a suspended component becomes ready to be rendered: the server generates its static HTML and RSC Payload and then streams both to the browser.<\/li>\n<\/ul>\n<h2 id=\"streaming\">Streaming<\/h2>\n<p>Streaming allows us to progressively render the UI from the server. With RSCs, each component is capable of fetching its own data. Some components are fully static and ready to be sent immediately to the client, while others require more work before loading. Based on this, Next.js splits that work into multiple chunks and streams them to the browser as they become ready. So, when a user visits a page, the server invokes all Server Components, generates the initial HTML for the page (i.e., the page shell), replaces the \u201csuspended\u201d components\u2019 contents with their fallbacks, and streams all of that through one or multiple chunks back to the client.<\/p>\n<p>The server returns a <code>Transfer-Encoding: chunked<\/code> header that lets the browser know to expect streaming HTML. This prepares the browser for receiving multiple chunks of the document, rendering them as it receives them. We can actually see the header when opening Developer Tools at the Network tab. Trigger a refresh and click on the document request.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/5-streaming-header.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"238\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Response header output highlighting the line containing the chunked transfer endcoding\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/5-streaming-header.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 5: Providing a hint to the browser to expect HTML streaming. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/5-streaming-header.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>We can also debug the way Next.js sends the chunks in a terminal with the <code>curl<\/code> command:<\/p>\n<pre><code class=\"language-bash\">curl -D - --raw localhost:3000 &gt; chunked-response.txt\n<\/code><\/pre>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/6-chunked-response.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"416\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Headers and chunked HTML payloads.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/6-chunked-response.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 6. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/6-chunked-response.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>You probably see the pattern. For each chunk, the server responds with the chunk\u2019s size before sending the chunk\u2019s contents. Looking at the output, we can see that the server streamed the entire page in 16 different chunks. At the end, the server sends back a zero-sized chunk, indicating the end of the stream.<\/p>\n<p>The first chunk starts with the <code><\/code> declaration. The second-to-last chunk, meanwhile, contains the closing <code><\/code> and <code><\/code> tags. So, we can see that the server streams the entire document from top to bottom, then pauses to wait for the suspended components, and finally, at the end, closes the body and HTML before it stops streaming.<\/p>\n<p>Even though the server hasn\u2019t completely finished streaming the document, the browser\u2019s fault tolerance features allow it to draw and invoke whatever it has at the moment without waiting for the closing <code><\/code> and <code><\/code> tags.<\/p>\n<h3 id=\"suspending-components\">Suspending Components<\/h3>\n<p>We learned from the render lifecycle that when a page is visited, Next.js matches the RSC component for that page and asks React to render its subtree in HTML. When React stumbles upon a suspended component (i.e., async function component), it grabs its fallback value from the <code><\/code> component (or the <code>loading.js<\/code> file if it\u2019s a Next.js route), renders that instead, then continues loading the other components. Meanwhile, the RSC invokes the async component in the background, which is streamed later as it finishes loading.<\/p>\n<p>At this point, Next.js has returned a full page of static HTML that includes either the components themselves (rendered in static HTML) or their fallback values (if they\u2019re suspended). It takes the static HTML and RSC payload and streams them back to the browser through one or multiple chunks.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/7-fallbacks-suspended-components.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Showing suspended component fallbacks\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/7-fallbacks-suspended-components.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 7. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/7-fallbacks-suspended-components.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>As the suspended components finish loading, React generates HTML recursively while looking for other nested <code><\/code> boundaries, generates their RSC payloads and then lets Next.js stream the HTML and RSC Payload back to the browser as new chunks. When the browser receives the new chunks, it has the HTML and RSC payload it needs and is ready to replace the fallback element from the DOM with the newly-streamed HTML. And so on.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/8-suspended-components-html.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"399\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Static HTML and RSC Payload replacing suspended fallback values.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/8-suspended-components-html.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 8. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/8-suspended-components-html.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>In Figures 7 and 8, notice how the fallback elements have a unique ID in the form of <code>B:0<\/code>, <code>B:1<\/code>, and so on, while the actual components have a similar ID in a similar form: <code>S:0<\/code> and <code>S:1<\/code>, and so on.<\/p>\n<p>Along with the first chunk that contains a suspended component\u2019s HTML, the server also ships an <code>$RC<\/code> function (i.e., <code>completeBoundary<\/code> from <a href=\"https:\/\/github.com\/facebook\/react\/blob\/main\/packages\/react-dom-bindings\/src\/server\/fizz-instruction-set\/ReactDOMFizzInstructionSetShared.js#L46\">React\u2019s source code<\/a>) that knows how to find the <code>B:0<\/code> fallback element in the DOM and replace it with the <code>S:0<\/code> template it received from the server. That\u2019s the \u201creplacer\u201d function that lets us see the component contents when they arrive in the browser.<\/p>\n<p>The entire page eventually finishes loading, chunk by chunk.<\/p>\n<h3 id=\"lazy-loading-components\">Lazy-Loading Components<\/h3>\n<p>If a suspended Server Component contains a lazy-loaded Client Component, Next.js will also send an RSC payload chunk containing instructions on how to fetch and load the lazy-loaded component\u2019s code. This represents a <em>significant performance improvement<\/em> because the page load isn\u2019t dragged out by JavaScript, which might not even be loaded during that session.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/9-fetching-lazy-loaded-scripts.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"442\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Fetching additional JavaScript and CSS files for a lazy-loaded Client Component, as shown in developer tools.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/9-fetching-lazy-loaded-scripts.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 9. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/9-fetching-lazy-loaded-scripts.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>At the time I\u2019m writing this, the dynamic method to lazy-load a Client Component in a Server Component in Next.js does not work as you might expect. To effectively lazy-load a Client Component, put it in a <a href=\"https:\/\/github.com\/nikolovlazar\/rsc-forensics\/blob\/main\/src\/components\/addToCartWrapper.js\">\u201cwrapper\u201d Client Component<\/a> that uses the <code>dynamic<\/code> method itself to lazy-load the actual Client Component. The wrapper will be turned into a script that fetches and loads the Client Component\u2019s JavaScript and CSS files at the time they\u2019re needed.<\/p>\n<h3 id=\"tl-dr\">TL;DR<\/h3>\n<p>I know that\u2019s a lot of plates spinning and pieces moving around at various times. What it boils down to, however, is that a page visit triggers Next.js to render as much HTML as it can, using the fallback values for any suspended components, and then sends that to the browser. Meanwhile, Next.js triggers the suspended async components and gets them formatted in HTML and contained in RSC Payloads that are streamed to the browser, one by one, along with an <code>$RC<\/code> script that knows how to swap things out.<\/p>\n<h2 id=\"the-page-load-timeline\">The Page Load Timeline<\/h2>\n<p>By now, we should have a solid understanding of how RSCs work, how Next.js handles their rendering, and how all the pieces fit together. In this section, we\u2019ll zoom in on what exactly happens when we visit an RSC page in the browser.<\/p>\n<h3 id=\"the-initial-load\">The Initial Load<\/h3>\n<p>As we mentioned in the TL;DR section above, when visiting a page, Next.js will render the initial HTML minus the suspended component and stream it to the browser as part of the first streaming chunks.<\/p>\n<p>To see everything that happens during the page load, we\u2019ll visit the \u201cPerformance\u201d tab in Chrome DevTools and click on the \u201creload\u201d button to reload the page and capture a profile. Here\u2019s what that looks like:<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/10-first-chunks-being-streamed.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"442\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Showing the first chunks of HTML streamed at the beginning of the timeline in DevTools.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/10-first-chunks-being-streamed.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 10. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/10-first-chunks-being-streamed.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>When we zoom in at the very beginning, we can see the first \u201cParse HTML\u201d span. That\u2019s the server streaming the first chunks of the document to the browser. The browser has just received the initial HTML, which contains the page shell and a few links to resources like fonts, CSS files, and JavaScript. The browser starts to invoke the scripts.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/11-first-frames.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"442\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"The first frames appear, and parts of the page are rendered\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/11-first-frames.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 11. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/11-first-frames.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>After some time, we start to see the page\u2019s first frames appear, along with the initial JavaScript scripts being loaded and hydration taking place. If you look at the frame closely, you\u2019ll see that the whole page shell is rendered, and \u201cloading\u201d components are used in the place where there are suspended Server Components. You might notice that this takes place around 800ms, while the browser started to get the first HTML at  100ms. During those 700ms, the browser is continuously receiving chunks from the server.<\/p>\n<p>Bear in mind that this is a Next.js demo app running locally in development mode, so it\u2019s going to be slower than when it\u2019s running in production mode.<\/p>\n<h3 id=\"the-suspended-component\">The Suspended Component<\/h3>\n<p>Fast forward few seconds and we see another \u201cParse HTML\u201d span in the page load timeline, but this one it indicates that a suspended Server Component finished loading and is being streamed to the browser.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/12-suspended-component.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" height=\"442\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"The suspended component\u2019s HTML and RSC Payload are streamed to the browser, as shown in the developer tools Network tab.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/12-suspended-component.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 12. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/12-suspended-component.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>We can also see that a lazy-loaded Client Component is discovered at the same time, and it contains CSS and JavaScript files that need to be fetched. These files weren\u2019t part of the initial bundle because the component isn\u2019t needed until later on; the code is split into their own files.<\/p>\n<p>This way of code-splitting certainly improves the performance of the initial page load. It also makes sure that the Client Component\u2019s code is shipped only if it\u2019s needed. If the Server Component (which acts as the Client Component\u2019s parent component) throws an error, then the Client Component does not load. It doesn\u2019t make sense to load all of its code before we know whether it will load or not.<\/p>\n<p>Figure 12 shows the <code>DOMContentLoaded<\/code> event is reported at the end of the page load timeline. And, just before that, we can see that the <code>localhost<\/code> HTTP request comes to an end. That means the server has likely sent the last zero-sized chunk, indicating to the client that the data is fully transferred and that the streaming communication can be closed.<\/p>\n<h3 id=\"the-end-result\">The End Result<\/h3>\n<p>The main <code>localhost<\/code> HTTP request took around five seconds, but thanks to streaming, we began seeing page contents load much earlier than that. If this was a traditional SSR setup, we would likely be staring at a blank screen for those five seconds before anything arrives. On the other hand, if this was a traditional CSR setup, we would likely have shipped <em>a lot<\/em> more of JavaScript and put a heavy burden on both the browser and network.<\/p>\n<p>This way, however, the app was fully interactive in those five seconds. We were able to navigate between pages and interact with Client Components that have loaded as part of the initial main bundle. This is a pure win from a user experience standpoint.<\/p>\n<h2 id=\"conclusion\">Conclusion<\/h2>\n<p>RSCs mark a significant evolution in the React ecosystem. They leverage the strengths of server-side and client-side rendering while embracing HTML streaming to speed up content delivery. This approach not only addresses the SEO and loading time issues we experience with CSR but also improves SSR by reducing server load, thus enhancing performance.<\/p>\n<p>I\u2019ve refactored the same RSC app I shared earlier so that it uses the Next.js Page router with SSR. The improvements in RSCs are significant:<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/13-ssr-vs-rscs.jpeg\"><\/p>\n<p>    <img decoding=\"async\" loading=\"lazy\" width=\"800\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Comparing Next.js Page Router and App Router, side-by-side.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/13-ssr-vs-rscs.jpeg\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Figure 13. (<a href=\"https:\/\/files.smashing.media\/articles\/forensics-react-server-components\/13-ssr-vs-rscs.jpeg\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Looking at these two reports I pulled from Sentry, we can see that streaming allows the page to start loading its resources before the actual request finishes. This significantly improves the Web Vitals metrics, which we see when comparing the two reports.<\/p>\n<p>The conclusion: <strong>Users enjoy faster, more reactive interfaces with an architecture that relies on RSCs.<\/strong><\/p>\n<p>The RSC architecture introduces two new component types: Server Components and Client Components. This division helps React and the frameworks that rely on it \u2014 like Next.js \u2014 streamline content delivery while maintaining interactivity.<\/p>\n<p>However, this setup also introduces new challenges in areas like state management, authentication, and component architecture. Exploring those challenges is a great topic for another blog post!<\/p>\n<p>Despite these challenges, the benefits of RSCs present a compelling case for their adoption. We definitely will see guides published on how to address RSC\u2019s challenges as they mature, but, in my opinion, they already look like the future of rendering practices in modern web development.<\/p>\n<div class=\"signature\">\n  <img decoding=\"async\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Smashing Editorial\" width=\"35\" height=\"46\" loading=\"lazy\" class=\"lazyload\" data-src=\"https:\/\/www.smashingmagazine.com\/images\/logo\/logo--red.png\"><br \/>\n  <span>(gg, yk)<\/span>\n<\/div>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>The Forensics Of React Server Components (RSCs) The Forensics Of React Server Components (RSCs) Lazar Nikolov 2024-05-09T13:00:00+00:00 2025-06-20T10:32:35+00:00 This article is sponsored by Sentry.io In this article, we\u2019re going to look deeply at React Server&hellip;<\/p>\n<p class=\"more-link-wrapper\"><a href=\"https:\/\/francecourier.com\/index.php\/2024\/05\/09\/the-forensics-of-react-server-components-rscs\/\" class=\"more-link\">Continue Reading<span class=\"screen-reader-text\"> &#8220;The Forensics Of React Server Components (RSCs)&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-581","post","type-post","status-publish","format-standard","hentry","category-business"],"_links":{"self":[{"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/posts\/581","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/comments?post=581"}],"version-history":[{"count":1,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/posts\/581\/revisions"}],"predecessor-version":[{"id":584,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/posts\/581\/revisions\/584"}],"wp:attachment":[{"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/media?parent=581"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/categories?post=581"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/francecourier.com\/index.php\/wp-json\/wp\/v2\/tags?post=581"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}