Next.js supports several rendering strategies, and the App Router chooses one automatically based on how a page uses dynamic data. Server-Side Rendering, or SSR, generates the HTML on the server for each incoming request. This mode is triggered when a page calls dynamic functions like cookies() or headers(), and it is appropriate when content must reflect per-user state or change frequently. Because every request triggers a fresh render, SSR is the most flexible but also the most expensive option, since the server must do work on every visit.
Static Site Generation, or SSG, generates HTML at build time. Pages without dynamic data are automatically pre-rendered and served as static files from a CDN, which makes them extremely fast and cheap to host. This is the default mode whenever the framework can prove that no request-scoped data is being read. For content that needs the speed of static delivery but also needs to stay reasonably fresh, Next.js offers Incremental Static Regeneration, or ISR.
With ISR, you can set a revalidate interval so that a previously generated page is regenerated in the background after a certain number of seconds. The example fetch(url, { next: { revalidate: 60 } }) instructs Next.js to serve cached content but refresh it every minute. The framework inspects the data access patterns inside your Server Components and picks the strategy that fits, so you can focus on writing the right code and let Next.js optimize delivery behind the scenes.