A core tenant of modern x js is that it tries to be as performant as possible unless you implicitly or explicitly do something, forcing it to opt for the more resource intensive path. One of these things is static versus dynamic rendering. Before we look at the code, let's solidify the concept of dynamic versus static rendering. Let's take a look at dynamic rendering When a request comes in for a particular page. Next, yes, we'll render out that page and we'll return the response that will be displayed by the user's browser. Now, as another request comes in for the same page,

the server will have to render the page again and then return the response. And as you can imagine, this is going to consume server resources. This is why by default next year we'll try to optimize and try to do static rendering. For static rendering, we split the rendering of a page between build time and runtime. Next year we'll observe if a particular route can be rendered statically, and if that is the case, it'll render it out at bill time and deploy it to an edge content delivery network. So now at runtime, if a request comes in for something

that has been statically rendered, it can be serviced directly by the Edge CDN and not consume our expensive server resources. It can be hard to know exactly which routes in next years are going to render dynamically and which routes are going to be static unless you look at all of the code in your project. Fortunately, the next JS build command does this analysis across your entire code base and logs out the static, which is dynamic routes as a part of its build output. To demonstrate that we have an example project that has static and dynamic pages, so let's run the next JS build.

Once the build completes, next J will log out the routes that it has discovered at the bottom of the output. We can see that next years has found dynamic as well as static pages. Our page at slash dynamic has been determined to be dynamic as indicated by the presence of the F and the slash static route has been determined to be static. A question you should have at this point is how does next year's determine if something should be statically or dynamically rendered by default? Next years will try to do static rendering, and here is a simple page. As you can see, this is something

that can be rendered statically as it is going to be the same response for everyone that queries this page, and therefore that is exactly what next GS has done. If we use APIs, that can cause the page to be different for different users. The next GS will automatically opt in for dynamic rendering. For that page. For our dynamic page, we are using the headers API provided by next headers. And since the headers are going to be different for different requests, next JS is smart enough to figure out that this page needs to be dynamic. As an example, this page uses the headers to display the current user agent.

So on Chrome, we would get one result, whereas on something like Safari, we would get a different result. Even though next J might determine something to be static, you can actually explicitly mark a particular route to be dynamic. Consider this example page that logs out the time when it is rendered. Using the standard JavaScript data. API is not something that next year considers as an option for moving the page to be dynamic. So if you were to build this application right now, you will see that despite using the data, API example is something that has been marked as a static page.

What this means is that in the running production application, as different requests are made for that page, the displayed time is not going to change as it is simply a snapshot of the time when that page was rendered. As a part of our build, we can actually force a particular route to be dynamic by using the next JS route segment config. The particular option that we are looking for is called dynamic. And in order to configure it, we simply export a constant variable called dynamic and set its value to one of the supported options. By default, it'll be auto, which means

that next JS will automatically figure out whether a page should be dynamic, a static. But here we are setting it to first dynamic, which means that next years will always consider this particular route as a dynamic route. And now when we build our replication, again, you can see that next years considers slash example to be a dynamic route as indicated by the presence of this F. To prove that when we run our built application as different requests are made by us reloading the browser, you can see that that timestamp is changing, indicating that that page is being rendered for each request.

As a final note, it is worthwhile knowing the complete list of things that will cause next years to opt into dynamic rendering for a particular route. And you can find this within the next JS documentation. Here is the complete list currently displayed on screen. It basically includes dynamic fetch requests along with dynamic APIs provided by next js. Now this list is bound to change over time, which is why it is important to understand how to look at the build output to see if a particular route is static or dynamic.