Faster Page Loads with Incremental Static Regeneration (PERF-22)
Faster Page Loads with Incremental Static Regeneration (PERF-22)
Version: 0.1.125
Category: Performance
Overview
As of v0.1.125, the home page and all legal pages are now statically generated rather than server-rendered on every request. This change eliminates unnecessary force-dynamic rendering and improves page load performance, particularly for unauthenticated and first-time visitors.
Background
Next.js supports several rendering strategies. Pages marked with export const dynamic = 'force-dynamic' are fully rendered on the server for every incoming request — equivalent to traditional SSR. While this is correct for highly personalised or frequently changing pages, it carries overhead: each visit triggers a full server round-trip, an auth() call, and a blocking render before any HTML reaches the browser.
The home page previously used force-dynamic solely to conditionally render a single CTA button ("Sign in" vs. "Go to dashboard"). Every other element on the page — headings, feature descriptions, legal links — is identical for all users. This meant thousands of requests each day were doing unnecessary server work to serve content that never changes.
The three legal pages (/privacy, /terms, /lawful-basis) had no dynamic content at all, yet were also being dynamically rendered.
What Was Changed
Home Page Refactor
The home page (src/app/page.tsx) has been refactored as follows:
force-dynamicremoved — Next.js now statically generates the page at build time and serves it from the CDN edge.<AuthCTA />client component introduced — The single auth-dependent element (the call-to-action button) has been extracted into a small client component. This component reads the user's session state in the browser after the static HTML has loaded, then renders the appropriate button variant.
This pattern — sometimes called "static shell with client islands" — means:
- The full page HTML is available instantly from the edge cache.
- Time-to-first-byte (TTFB) drops significantly for cold visitors.
- The CTA still reflects authentication state correctly; it just hydrates slightly after initial paint rather than being resolved on the server.
Before: Request → Server → auth() call → Full SSR → Response
After: Request → CDN Edge → Static HTML → Client hydrates <AuthCTA />
Legal Pages
The privacy (/privacy), terms (/terms), and lawful-basis (/lawful-basis) pages had dynamic export directives that were serving no purpose. These have been removed. Next.js now auto-detects them as fully static at build time — no server involvement at runtime whatsoever.
Impact
| Page | Before | After |
|---|---|---|
/ (Home) | Full SSR on every request | Static HTML from CDN; <AuthCTA /> hydrates client-side |
/privacy | Dynamic SSR | Static at build time |
/terms | Dynamic SSR | Static at build time |
/lawful-basis | Dynamic SSR | Static at build time |
Notes for Developers
- The
<AuthCTA />component is a client component ('use client'). It should remain lightweight and must not import server-only modules. - If the home page ever requires additional personalisation beyond the CTA, consider whether that content can similarly be isolated into a client component rather than reverting the whole page to
force-dynamic. - Legal pages should never need dynamic rendering unless legally mandated content changes in real time. Keep them static.