A lot of developers struggle with caching in next years, so let's do a quick recap of what we've already learned and how to apply it effectively. For pages, you can think of next year's caching is nothing more than a rendering strategy. With SST, the page is rendered at build time and then caged indefinitely. This is the same as static rendering. With SSR, it is always rendered on request time, so essentially the page output is never caged, and this is the same as dynamic rendering. And finally, we have ISR or incremental static rendering, which is a mix between the two.

The result is caged, but it comes with the revalidation timeout. Essentially, the page is static initially, but from time to time that static output is refreshed, therefore making it dynamic. The reason why many people struggle with Cing is that it's disabled during development. To demonstrate, consider a simple page where we make a request to an external API to fetch a random number, and then we display that within the user interface as a random winner. Now, this code looks perfectly fine and you think that there is no issue with your logic, but to be sure you test it out during development, and no surprise, it works as expected.

Every time we refresh the page, we get a new random winner, so you decide to push it to production and call it a day. However, that would be a mistake because you forgot about the aggressive caching optimizations that are built into next js. To demonstrate that, let's run a production build and then start our production server. When you visit the same page on production, it seems to work fine. However, when we refresh, we do not get new random numbers, and you start scratching your head, why did it work in development and not in production? This brings us to the golden rule of caching. In Next, always, always, always validate caching in a production build.

With this golden rule out of the way, let's just fix this production build. We've already looked at how the fetch requests are caged, and if you don't want them to be cached, you can pass in the option cache, no store. As an aside, the reason why caching is disabled during development is that if caching was enabled, it would make for a very frustrating and confusing developer experience. I could bore you to death with the hundreds of ways that you can configure the caching next years. But let's provide you with a simple guide to get you through 99% of the issues. Here's your simple guide to successfully exploiting next year's caching.

For fun and profit, it comes in three stages. You can choose to make your life easy. You can choose to save some money, or you can choose to save all the money. If you just want to make your life easy, then mark your route. As force dynamic, you might burn some cash, but at least your application will work. When you are ready to save some money, start sprinkling revalidation timeouts to your routes. This way, your application is still mostly dynamic, but you get to save on some server resources and when you assure that your content is not going to change after a successful build, you can mark your route

with full static.