PERF-19: Static Generation Audit — Findings & Recommendations
PERF-19: Static Generation Audit — Findings & Recommendations
Release: v1.0.82 · Category: Performance — Build & Deploy
This document covers the findings from the PERF-19 static generation audit and the concrete steps planned to improve build-time rendering across the platform.
Background
Next.js supports several rendering strategies — full Static Site Generation (SSG), Incremental Static Regeneration (ISR), and server-side rendering (SSR/force-dynamic). Choosing the right strategy per page type directly affects:
- Time to First Byte (TTFB) for end users
- Build output size and cold-start performance on serverless infrastructure
- Origin load under traffic spikes
As the platform grows, ensuring that only pages which genuinely require runtime data are marked force-dynamic is important for keeping the application fast and cost-efficient.
What Was Audited
All pages under src/app/ were reviewed for the presence of:
export const dynamic = 'force-dynamic'export const revalidate = <seconds>generateStaticParams()on dynamic route segments
Findings
Dashboard Pages (/dashboard/*)
All dashboard pages explicitly export:
export const dynamic = 'force-dynamic';
This is correct behaviour. Dashboard pages are authentication-protected and serve per-user, per-OMC data that cannot be pre-rendered at build time.
Dynamic Routes
| Route | generateStaticParams | Assessment |
|---|---|---|
/dashboard/developments/[id] | ❌ Not defined | Correct — auth-protected, runtime data |
/dashboard/omc/[developmentId] | ❌ Not defined | Correct — auth-protected, runtime data |
These routes correctly avoid static params generation. Because they sit behind authentication and render OMC-specific data, pre-rendering them at build time would be neither possible nor appropriate.
Public / Semi-Static Pages
| Page | revalidate | dynamic | Assessment |
|---|---|---|---|
/pricing | ❌ None | ❌ None | Should use ISR |
/terms | ❌ None | ❌ None | Should use ISR |
/sign-in | ❌ None | ❌ None | Should be fully static |
These pages have no dynamic or user-specific content but are currently rendered on-demand on every request. This is an unnecessary performance cost.
Recommendations
1. Enable ISR on /pricing and /terms
Add the following export to both src/app/pricing/page.tsx and src/app/terms/page.tsx:
// Revalidate once per hour
export const revalidate = 3600;
This tells Next.js to serve a cached static version of the page and regenerate it in the background at most once per hour. Content updates will propagate without a full redeploy.
2. Fully Statically Generate /sign-in
The sign-in page contains no dynamic content and does not read from any data source at request time. It is a candidate for full static generation — no revalidate export needed, and dynamic should not be set to 'force-dynamic':
// No dynamic export — Next.js will statically generate this page at build time
// export const dynamic = 'force-dynamic'; ← Remove this if present
3. Extract a Static Dashboard Layout Shell
The dashboard sidebar navigation does not change per-request — it is driven by the authenticated user's role, but the structural shell (logo, nav items, layout) is static. Extracting this into a standalone static component and avoiding force-dynamic on the layout itself will allow Next.js to pre-render the shell, reducing visible layout shift and improving perceived performance.
What Has Not Changed
This release is audit-only. No changes to rendering behaviour have been made in v1.0.82. The findings and recommendations above are tracked for implementation in follow-up releases.