Dynamic Rendering: On-Demand Pages in Next.js

WHY IT EXISTS: Some web pages can't be built ahead of time. Their content depends on who the user is, what they've searched for, or data that changes every second. Static generation fails here, so a mechanism is needed to build the page on-demand, just before it's sent to the user.

THE MENTAL MODEL: Think of it like a restaurant's à la carte menu versus a buffet. Static generation is the buffet: all dishes are prepared in advance and served instantly. Dynamic Rendering is à la carte: the chef (server) cooks your specific dish (page) only after you order (request it), ensuring it's fresh and exactly what you asked for.

HOW IT WORKS: When a user requests a dynamically rendered page, the request hits the Next.js server. The server runs code to fetch any necessary data and then uses React to render the page components into HTML. This final HTML is sent to the user's browser. In the App Router, this behavior is triggered automatically for pages that use dynamic functions (like cookies() or headers()) or have uncached data fetches. In the older Pages Router, this was explicitly enabled by exporting a function called getServerSideProps.

WHEN TO USE IT: Use dynamic rendering for pages that must be unique for each user or request. Good examples include a user's account dashboard, a search results page based on a query, or a page showing live, real-time information. It's necessary when you need to read cookies or headers on the server to decide what content to show.

WHEN NOT TO USE IT: Avoid dynamic rendering for pages where the content is the same for all users and doesn't change often. Marketing pages, blog posts, and product documentation are poor candidates. Using dynamic rendering for these adds unnecessary server load and slows down the user experience compared to static generation. If a page can be built once and served to everyone, it should be.

ONE CANONICAL EXAMPLE: A user profile page (/profile) must be dynamically rendered. The server needs to identify the logged-in user (e.g., from a cookie), fetch their specific data from a database, and then render the HTML with their name and information. This process must happen for every request to /profile because the content is different for every user.