Faster Marketing Pages with Static Generation (PERF-19)

Release: v1.0.416
Category: Performance · Build & Deploy

Overview

As of v1.0.416, all public marketing pages on the platform are statically generated at build time using Next.js Incremental Static Regeneration (ISR). This means they are pre-rendered to HTML, cached at Vercel's CDN edge, and served globally without invoking a serverless function on every request.

Background

Next.js distinguishes between three rendering strategies:

• force-dynamic — the page is rendered on every request by a serverless function. Correct for authenticated pages that depend on session or real-time data.
• Default dynamic — Next.js decides at runtime; without explicit static configuration, pages still incur cold-start overhead.
• Static / ISR — the page is built once and cached. With ISR, a revalidate interval triggers a background rebuild so content stays fresh without blocking visitors.

Before this change, the root landing page (/) was explicitly marked force-dynamic, and the other marketing pages had no static configuration. All of them contained only static content, making the serverless invocations entirely unnecessary.

Changes Made

src/app/page.tsx (Landing page)

- export const dynamic = 'force-dynamic'
+ export const revalidate = 3600

The landing page now revalidates in the background at most once per hour. The 1-hour window accounts for any occasional copy or promotional updates that may appear here more frequently than on legal pages.

src/app/pricing/page.tsx, privacy/page.tsx, terms/page.tsx, ropa/page.tsx

// Added to each file
export const revalidate = 86400 // 24 hours

These pages change very infrequently. A 24-hour revalidation window ensures CDN caches are refreshed within a day of any content update while keeping edge-served hit rates extremely high.

What stays the same

All authenticated dashboard pages continue to use export const dynamic = 'force-dynamic'. This is intentional and correct — those pages render per-user data (tax submissions, transaction imports, HMRC OAuth state, etc.) that must never be cached across sessions.

Performance impact

Metric	Before	After
Serverless invocations per marketing page visit	1	0 (cache hit)
Time-to-first-byte (TTFB)	~200–800 ms (cold start)	~20–50 ms (CDN edge)
Build artefacts	None for these routes	Static HTML + JSON at build time
Cache invalidation	N/A	Automatic background revalidation

How ISR revalidation works

1. At build time, Next.js pre-renders the page to static HTML.
2. Vercel caches this HTML at edge nodes globally.
3. After the revalidate interval expires, the next request triggers a background re-render. The current visitor still receives the cached version instantly.
4. Once the background render completes, subsequent visitors receive the freshly generated page.

This means content updates propagate within one revalidation window with zero downtime and no manual cache purging required.