Page cache and revalidation
In this chapter you will learn about NextJS' static pages and how the Enonic triggers re-generation of pages when publishing.
The NextJS front-end is configured to use static page generation (ISR), which basically means you get lightning fast pages, but also with specific limitations, such as getting new pages and changes instantly live on your site.
|Next.js also supports Server Side Rendering (SSR) which can be enabled by modifying the
[[…contentPath]].tsx page handler. In this mode all rendering will be "real time", meaning no caching.
So far, you have been running Next.js in dev mode.
By starting Next.js in
prod mode, the application is automatically optimized, and in our case, pages get pre-rendered statically at compile time.
|Remember to stop your existing Next.js dev instance before you continue.
Start Next.js in prod mode:
npm run prod
This will take a while longer as when compared to dev mode.
Verify by pointing your browser to http://localhost:4242, you should now see the published items, just like in dev mode. Sweet!
With Next.js now running on a different port, the preview integration we configured earlier has been broken.
Fix the preview by updating the Next.XP app configuration on your site with the new URL, and confirm that preview starts working again.
|Content Studio uses Next.js' preview mode, which automatically bypass static pages, always showing the the latest updates to your draft content.
Edit your front-page, and publish the changes. This will trigger a revalidation hook.
Despite using static pages, the page should get updated at
http://localhost:4242 with your latest changes - more or less instantly. 🎉
How does it work? In addition to handling previews, the Next.XP app automatically triggers revalidation of all pages when it detects the publishing event.
|You should also be able to tell from the Next.js log that the revalidation was triggered.
With prod mode and revalidation sorted out, its about time you deploy your apps to live servers.