Rendering Strategies & Delivery

CDN & Edge Infrastructure

The primary goal of Next.js is to minimize the distance between the user and the server. This is achieved through a Content Delivery Network.

The Origin vs. The Edge

• The Origin Server: The central server where our application code executes and where our database resides.
• The Edge CDN Servers: Thousands of lightweight servers distributed globally. They act as the last mile of the internet, serving cached content to users from a nearby physical location.

The Last Mile Optimization

When a route is rendered Statically, Next.js produces the HTML and RSC Payload during the build process. These files are pushed to the Edge Servers once user from region of edge server makes request for web page.

1. Cache HIT: A user in London requests our page. The London Edge server already has the HTML/Payload. It serves them in milliseconds. The request never reaches our Origin Server.
2. Cache MISS: If the Edge doesn't have the file, it fetches it from the Origin, serves the user, and then caches a copy for the next user in that region.

---

Static vs. Dynamic Classification

During next build, Next.js performs Static Analysis to categorize every route segment. This decision determines timing of rendering i.e. if the work is done once (at build) or for every user (at request).

Static Rendering

Next.js assumes all routes are static until proven otherwise. The server renders the component once, and the resulting HTML and RSC Payload are frozen and pushed to the CDN. What do you mean by pushed to CDN ? The HTML and RSC Payload were supposed to be cached on Edge Server once user from that region makes request for it right ?

Dynamic Rendering

If a route depends on information that only exists at the moment of the visit, Next.js skips the CDN cache and executes the code on the Origin Server for every request.

The Opt-out Cascade: If a Layout is dynamic, the entire branch of the tree becomes dynamic. However, a dynamic Page can sit inside a static Layout.

---

Dynamic Functions: The Request Time Triggers

There are specific APIs that force Next.js to switch to Dynamic Rendering because they require Request time context:

1. cookies(): Accessing user specific sessions or preferences.
2. headers(): Inspecting incoming HTTP request data (e.g., Auth tokens).
3. searchParams: URL query strings (e.g., ?query=next). Since query strings are infinite and unpredictable, they cannot be pre rendered at build time.

---

ISR (Incremental Static Regeneration)

ISR is the Hybrid model. It allows us to update static artifacts in the background without a full redeploy, using the Stale-While-Revalidate (SWR) pattern.

The Execution Lifecycle:

1. User A visits: Receives a Stale (cached) version instantly from the CDN.
2. Trigger: If the revalidation timer has expired, the CDN tells the Origin to re render the page in the background.
3. Update: The Origin generates a fresh HTML/RSC Payload and replaces the stale version on the CDN.
4. User B visits: Receives the Fresh version.

---

📝 Performance Comparison Matrix

---

🛑 Stop and Think

The Architectural Priority: Your goal as an architect is to maximize Static Rendering. This shifts the Compute Cost from the user's visit to the deployment phase. Use Dynamic Rendering only for private, user-specific data that cannot be cached on a public CDN.

---