Back to blog
This post is on the way.
Reading
post
The piece is being set. The cover and the first lines land here.
Back to blog
This post is on the way.
Reading
post
The piece is being set. The cover and the first lines land here.
Back to blog
Reading
The piece is being set. The cover and the first lines land here.
Back to blog
Reading
The piece is being set. The cover and the first lines land here.
Back to blog
Reading
The piece is being set. The cover and the first lines land here.
24 Feb 2026 · Brook · react · edge computing
In an era of instant digital experiences, users expect web applications to load in milliseconds. Traditional rendering strategies such as Client-Side Rendering (CSR) and Server-Side Rendering (SSR) have powered the web for years, but both introduce performance tradeoffs.
Two architectural advancements are reshaping modern frontend performance:
Together, they redefine how and where code executes, and how quickly users receive meaningful content.
With CSR, the browser receives a minimal HTML shell along with a JavaScript bundle. The browser then:
This creates a network waterfall. On slower devices or constrained networks, users often see blank screens or loading states before meaningful content appears. Search engines may also struggle because the initial HTML contains little usable content.
SSR generates HTML on the server before sending it to the browser. This improves SEO and avoids blank initial screens. However, it introduces different constraints:
If your infrastructure is centralized and your audience is global, network distance becomes a real performance constraint.
React Server Components are components that render on the server and do not ship their JavaScript to the browser.
They:
A critical clarification:
There is no "use server" directive for Server Components. They are the default in supported environments.
The "use server" directive applies to Server Functions, not components.
Traditional client-side data fetching requires:
With Server Components, the database call runs during server rendering. The browser receives fully prepared HTML, without extra API routes, useEffect hooks, or client-side waterfalls.
This reduces bundle size, simplifies architecture, and improves first content delivery.
Server Components handle:
Client Components handle:
Only Client Components ship JavaScript to the browser. Data-fetching logic remains server-side.
This separation significantly reduces client bundle weight and improves initial load performance while preserving interactivity.
React Server Components integrate with Suspense to enable streaming responses.
Instead of waiting for the entire page to finish rendering:
Streaming improves perceived performance and helps critical content appear earlier.
Even highly optimized server rendering faces a physical constraint: distance.
If your application runs in a single region and a user connects from another continent, every request travels thousands of kilometers before processing begins. That network round trip alone can add significant latency, independent of application logic.
Edge Rendering moves compute closer to users.
Instead of rendering in a centralized origin, your application executes on globally distributed edge nodes, often built on CDN infrastructure. When a request arrives:
This shifts the performance bottleneck away from distance and toward application design.
However, edge rendering is not simply a speed upgrade. It changes execution environments and introduces trade-offs.
Traditional SSR:
Edge Rendering:
The difference is not faster versus slower.
It is proximity versus capability.
If your workload is lightweight HTML generation and request handling, edge execution can meaningfully reduce time-to-first-byte for global audiences.
If your application depends on heavy computation, TCP database drivers, or long-running processes, traditional SSR may remain the better fit.
Strategy | Renders Where | Latency Profile | SEO | Best Use Case |
|---|---|---|---|---|
CSR | Browser | High due to JavaScript waterfall | Limited | Internal dashboards |
SSR | Single origin | Region-dependent | Strong | Data-driven applications |
Edge Rendering | Distributed edge nodes |
Edge Rendering preserves SSR’s SEO benefits while reducing geographic latency.
The advantages are most visible when:
If your audience is concentrated in a single region, traditional SSR may perform similarly.
Edge runtimes are optimized for fast startup and lightweight execution. They perform best for:
These tasks are stateless and compute-efficient, making them ideal for distributed environments.
In frameworks like Next.js, middleware can run at the edge before your application logic executes.
This enables:
Edge middleware is often the most practical first step toward adopting edge architecture.
Before adopting edge rendering, understand its limitations:
Edge environments are optimized for request-response workloads, not heavy background tasks.
Complex processing and large memory workloads should remain in traditional server environments.
Modern web architecture can be viewed in three layers:
Handles:
Handles:
Handles:
When deciding where logic belongs, ask:
This layered model encourages clarity, separation of concerns, and performance efficiency.
24 Feb 2026 · Brook · react · edge computing
In an era of instant digital experiences, users expect web applications to load in milliseconds. Traditional rendering strategies such as Client-Side Rendering (CSR) and Server-Side Rendering (SSR) have powered the web for years, but both introduce performance tradeoffs.
Two architectural advancements are reshaping modern frontend performance:
Together, they redefine how and where code executes, and how quickly users receive meaningful content.
With CSR, the browser receives a minimal HTML shell along with a JavaScript bundle. The browser then:
This creates a network waterfall. On slower devices or constrained networks, users often see blank screens or loading states before meaningful content appears. Search engines may also struggle because the initial HTML contains little usable content.
SSR generates HTML on the server before sending it to the browser. This improves SEO and avoids blank initial screens. However, it introduces different constraints:
If your infrastructure is centralized and your audience is global, network distance becomes a real performance constraint.
React Server Components are components that render on the server and do not ship their JavaScript to the browser.
They:
A critical clarification:
There is no "use server" directive for Server Components. They are the default in supported environments.
The "use server" directive applies to Server Functions, not components.
Traditional client-side data fetching requires:
With Server Components, the database call runs during server rendering. The browser receives fully prepared HTML, without extra API routes, useEffect hooks, or client-side waterfalls.
This reduces bundle size, simplifies architecture, and improves first content delivery.
Server Components handle:
Client Components handle:
Only Client Components ship JavaScript to the browser. Data-fetching logic remains server-side.
This separation significantly reduces client bundle weight and improves initial load performance while preserving interactivity.
React Server Components integrate with Suspense to enable streaming responses.
Instead of waiting for the entire page to finish rendering:
Streaming improves perceived performance and helps critical content appear earlier.
Even highly optimized server rendering faces a physical constraint: distance.
If your application runs in a single region and a user connects from another continent, every request travels thousands of kilometers before processing begins. That network round trip alone can add significant latency, independent of application logic.
Edge Rendering moves compute closer to users.
Instead of rendering in a centralized origin, your application executes on globally distributed edge nodes, often built on CDN infrastructure. When a request arrives:
This shifts the performance bottleneck away from distance and toward application design.
However, edge rendering is not simply a speed upgrade. It changes execution environments and introduces trade-offs.
Traditional SSR:
Edge Rendering:
The difference is not faster versus slower.
It is proximity versus capability.
If your workload is lightweight HTML generation and request handling, edge execution can meaningfully reduce time-to-first-byte for global audiences.
If your application depends on heavy computation, TCP database drivers, or long-running processes, traditional SSR may remain the better fit.
Strategy | Renders Where | Latency Profile | SEO | Best Use Case |
|---|---|---|---|---|
CSR | Browser | High due to JavaScript waterfall | Limited | Internal dashboards |
SSR | Single origin | Region-dependent | Strong | Data-driven applications |
Edge Rendering | Distributed edge nodes |
Edge Rendering preserves SSR’s SEO benefits while reducing geographic latency.
The advantages are most visible when:
If your audience is concentrated in a single region, traditional SSR may perform similarly.
Edge runtimes are optimized for fast startup and lightweight execution. They perform best for:
These tasks are stateless and compute-efficient, making them ideal for distributed environments.
In frameworks like Next.js, middleware can run at the edge before your application logic executes.
This enables:
Edge middleware is often the most practical first step toward adopting edge architecture.
Before adopting edge rendering, understand its limitations:
Edge environments are optimized for request-response workloads, not heavy background tasks.
Complex processing and large memory workloads should remain in traditional server environments.
Modern web architecture can be viewed in three layers:
Handles:
Handles:
Handles:
When deciding where logic belongs, ask:
This layered model encourages clarity, separation of concerns, and performance efficiency.
Region-aware and low
Strong |
Global applications |
Region-aware and low
Strong |
Global applications |