This Site Is Very Quick! It Uses SSG and ISR

I'm not a fan of waiting. We spend enough time doing it every day — waiting in traffic, for videos to buffer, for Excel to open. Wherever possible, I do everything I can to minimize those wait times. It simply offers a far superior experience for the end-user to have components show in an instant, rather than rely on spinners and skeletons. That's why I chose to implement Static Site Generation (SSG) with Incremental Static Regeneration (ISR) for this website. You'll feel its low-latency power as you click around.

With SSG, web pages are pre-rendered into static HTML, CSS, and JavaScript files during the build process. The major advantage here is that when a user requests a page, there's no need for the server to dynamically generate it. Instead, it instantly serves an already-prepared static file, and that is usually very quick. This approach provides a notably faster user experience compared to Client-Side Rendered (CSR) pages, where the browser's DOM handles content rendering at runtime.

The issue with using SSG in isolation is that content updates require a full rebuild for changes to show. While some CMS solutions and hosting providers accommodate—and even embrace—this "build on every commit" approach, I'm not a fan. I'd rather a solution that only rebuilds the HTML for new or updated pages, while leaving everything else untouched, no need for redeployment. That's where ISR comes in as SSG's perfect match. ISR introduces a mechanism to revalidate and regenerate individual static pages in the background.

You know those community libraries that pop up in leafy neighborhoods? Imagine one of those display cases: when using SSG by itself, every time someone wants to add their book to the community library, the contributor has to literally smash the glass casing, take all the books out, put all the books back in order with the new book, and then re-install brand new glass—a time-consuming, and inefficient process for even the smallest change. Similar to how pure SSG requires a full site rebuild for any content update.

Now, picture that same display case with a clever, hidden latch, representing ISR. When a book needs changing, visitors still immediately see the organized display through the glass; however, in the background, the contributor quietly opens the latch, makes the single book change, and re-latches the case. The next person who walks up will see the updated book immediately. ISR offers a smart, efficient way to update content without the constant "smashing and rebuilding" of the entire display.

But how does my site know when to "open the latch" and regenerate pages? There are primarily two methods to achieve this. One common approach is time-based revalidation, where you set a fixed interval – say, 6 hours – after which the page is considered stale. Upon the next request after this interval, the cached page is served immediately while a fresh version is regenerated in the background.

The other method is on-demand revalidation, often triggered via webhooks. Since I use Strapi for my CMS, I can leverage its webhook support: when content is created, updated, or deleted, a request is automatically sent to my API endpoint, which then explicitly causes the revalidation of the relevant page.

If you want the same experience for your website, I highly recommend this guide on How to implement Incremental Static Regeneration for Next.JS. However you implement SSG, you should see an instant improvement in load times when compared to CSR or SSR.