There are little tips on how we can minimize Data Transfer costs on Vercel when using React Server components. May we have a few guidelines and perhaps tips to measure if we’re optimizing successfully?
Additionally, knowing that React Server components also stream directly from server to client, does that mean it uses Fast Data Transfer instead of Fast Origin Transfer?
Another question, we tried using ISR (const dynamic = force-static) on top of an RSC. And the result was just that a heavier RSC payload size of 70kB is seen in the Network Tab. Our average response size increased as well. Is the old ISR still relevant when using React Server Components?
1. “Does streaming RSCs directly use FDT instead of FOT?”
Yes, essentially!
When you stream a React Server Component, the data is being sent from the Vercel function (the origin) to the client. This is classified as Fast Data Transfer (FDT) which is the data moving from Vercel’s network out to the user.
Fast Origin Transfer (FOT) usually refers to data moving from your own external origin (like an S3 bucket or your own database) into the Vercel network. Since RSC payloads are generated on the Vercel server and sent out, they contribute to your FDT.
2. “Why did using ISR (force-static) result in a heavier RSC payload (70kB)?”
When you use force-static (ISR), Next.js pre-renders the RSC payload and stores it.
Sometimes, a “static” version of a page includes the full serialized data needed to hydrate the entire tree at once, whereas a dynamic, streamed page might send smaller chunks over time.
If your “average response size” increased, check if you’re passing large objects as props to Client Components. In a static build, those objects get serialized into the HTML/RSC payload.
Before passing data to a Client Component, strip out any properties you don’t actually use. Creating a “DTO” (Data Transfer Object) on the server can drastically shrink that 70kB payload!
3. “Is ‘old’ ISR still relevant with RSCs?”
ISR is still one of the best tools for performance and cost.
FDT vs. Execution: While ISR doesn’t necessarily reduce the size of the payload, it drastically reduces Serverless Function Execution time. Instead of running the logic to fetch data and render components on every single request, Vercel serves the pre-rendered payload from the Edge.
The Strategy: Use ISR for high-traffic pages that don’t change every second. You’ll save a ton on compute costs, even if the FDT (the bytes sent) remains similar.
4. “How can we measure if we’re optimizing successfully?”
To see if your tweaks are actually working, I recommend two main views in your Vercel Dashboard:
Observability Tab: Look for spikes in “Edge Request Size” and “Serverless Function Execution.”
Usage Tab: Drill down into “Fast Data Transfer” to see which specific routes are the “heaviest.”
Pro Tip: Run npm run analyze (using @next/bundle-analyzer). It won’t show you the RSC payload size directly, but it will show you if your Client Components are dragging in massive libraries that bloat the initial load.
This might be a good video to watch because it demonstrates how React Server Components improve performance through real-time streaming and optimized interactivity, directly addressing the core mechanics of FDT.
