Smarter APIs with Static Generation (SSG) & ISR in Next.js for Scalable Pages

This document showcases how to leverage for Static Site Generation (SSG) and the option for Incremental Static Regeneration (ISR) in Next.js to build scalable and performant product or event pages. We'll explore the benefits of SSG over Server-Side Rendering (SSR) and illustrate the improvements through diagrams and comparisons.

Building Scalable Product/Event Pages

Product and event pages often share a similar structure but display dynamic content fetched from an API. Generating these pages on every request (SSR) can lead to performance bottlenecks under high traffic. SSG offers a solution by pre-rendering pages at build time, resulting in faster initial loads and improved SEO. However, the data for products and events is often updated, requiring a mechanism to refresh the static pages without a full rebuild. This is where ISR comes into play.

When to Choose SSG over SSR:

Consider using SSG when:

• Data is mostly static or changes infrequently: Product descriptions, event details that don't update every second.

• SEO is crucial: Pre-rendered HTML is easily crawlable by search engines.

• Performance is a priority: Serving pre-rendered HTML is significantly faster than server-rendering on each request.

• Reduced server load: Offloads rendering work to the build process.

Avoid SSG (and prefer SSR or Client-Side Rendering - CSR) when:

• Data is highly dynamic and changes frequently: Real-time stock tickers, live dashboards.

• User-specific data is required on the initial load: Personalized recommendations, authenticated content.

• Content cannot be known at build time: User-generated content without pre-defined structures.

How SSG Improves Performance:

SSG pre-renders HTML pages at build time. This means when a user requests a page, the server directly serves the static HTML file, bypassing the need to dynamically generate it. This leads to:

• Faster Time to First Byte (TTFB): The browser receives the initial HTML much quicker.

• Improved First Contentful Paint (FCP) and Largest Contentful Paint (LCP): Users see content on their screen faster, improving perceived performance.

• Reduced Server Load: The server only needs to serve static files, requiring fewer resources and handling more concurrent users.

• Better CDN Caching: Static assets can be easily cached by CDNs globally, further reducing latency.

Implementation with getStaticProps() and revalidate:

Let's consider a product page ().

1. Architecture Diagram:

• Build Time: When the Next.js application is built, fetches product data from the data source for each product ID defined in (or for all products if no is used with fallback). This data is then used to pre-render the HTML pages.

• Request Time (Cache Hit): When a user requests a product page, the CDN (if used) or the Next.js server directly serves the pre-rendered static HTML file if it's in the cache.

• Request Time (Cache Miss - Initial): If the page is not in the cache, the server serves the pre-rendered HTML.

• Background Revalidation (with ): After the initial request, if the option is set in , Next.js will regenerate the page in the background on the server on the next request after the revalidation interval has passed. The user will still receive the cached (potentially stale) version immediately. Once the background regeneration is complete, subsequent requests will serve the updated page.

2. Code Example ():

Explanation:

• : This function defines which product page paths should be pre-rendered at build time. It fetches all product IDs from the API and returns an array of . : This enables incremental static regeneration. If a user requests a product page that hasn't been pre-rendered yet, Next.js will: Serve a fallback version (the message in this case). In the background, fetch the data and generate the static HTML for that product. Subsequent requests to the same URL will serve the newly generated static page.

• : This function fetches the data for a specific product based on the from the URL parameters (). It runs at build time for the paths defined in and at revalidation intervals. : The fetched product data is passed as props to the component. : This crucial option enables ISR. After the initial static generation, Next.js will regenerate the page in the background at most every 60 seconds when a user visits it.

3. Flow Diagram (Request Lifecycle with ISR):

Before vs After Comparisons:

Let's consider a scenario with 10,000 product pages and high traffic.

Before (SSR):

• Performance: Each request to a product page triggers a server-side rendering process. This involves fetching data from the API and generating HTML on the fly. Under high load, the server can become overwhelmed, leading to slow response times and a poor user experience.

• TTFB: High, as the server needs to perform computations for every request.

• Server Load: Very high, as the server handles rendering for every user.

• Scalability: Limited by the server's capacity to handle concurrent requests.

• UX: Slow loading times can lead to higher bounce rates and lower engagement.

After (SSG with ISR):

• Performance: The initial load is significantly faster as the browser receives pre-rendered HTML directly from the CDN or server. Subsequent requests within the revalidation window also benefit from the cached static content.

• TTFB: Low, as the server serves static files almost instantly.

• Server Load: Significantly reduced, as the server only needs to serve static files most of the time and handles background revalidation periodically.

• Scalability: Highly improved, as the infrastructure can handle much higher traffic due to the reduced server load and efficient CDN caching.

• UX: Faster loading times lead to a smoother and more enjoyable user experience, potentially improving conversion rates and engagement.

Think of the performance gains like this:

Optimization:

• Strategic Interval: Choose a revalidation interval that balances data freshness with build frequency and server load. For frequently updated data, a shorter interval might be necessary, while less dynamic content can have a longer interval.

• CDN Usage: Leverage a Content Delivery Network (CDN) to cache the pre-rendered HTML files globally, reducing latency for users in different geographical locations.

• Efficient Data Fetching: Optimize API calls within to fetch only the necessary data.

• Fallback Pages: Provide a meaningful fallback UI () to keep users engaged while a new static page is being generated in the background.

• Monitoring: Monitor the performance of your pages and adjust the interval as needed.

By strategically using for SSG and the option for ISR in Next.js, you can build highly scalable and performant product and event pages. This approach delivers a superior user experience through faster initial loads, reduces server load, and improves SEO, making it an ideal choice for content that benefits from pre-rendering with the ability to update over time. Understanding when to choose SSG over SSR and carefully configuring the revalidation strategy are key to maximizing the benefits of this powerful Next.js feature.

Portfolio:

Edward Odhiambo

GitHub

GitLab