Static-first is an architectural constraint
Static-first does not mean avoiding a modern framework. It means deciding that public content should work as a generated artifact unless an interaction genuinely requires runtime behavior.
The App Router can still provide component composition, metadata, dynamic route generation, and typed content at build time.
Keep public components server-rendered
Navigation, content sections, case studies, legal pages, and articles do not require client state. Keeping them as Server Components reduces the application runtime surface and makes accidental dependencies easier to detect.
Native HTML elements such as links, details, forms, and media can cover many interactions without hydration.
Export every known route
Static export requires every dynamic route to be known at build time. Content collections should provide the slugs used by generateStaticParams, and the sitemap should be derived from the same source.
This produces predictable HTML files that can be verified before deployment.
Remove runtime only when it is safe
Framework script removal is not a general optimization technique. It is safe only when the build confirms that no application client modules depend on those scripts.
A fail-closed finalizer should stop the build when client references are present, then verify that the resulting HTML keeps structured data and project-owned scripts while removing framework runtime nodes.
Test the artifact
After finalization, inspect the exported homepage for an H1, canonical link, required structured data, and the absence of framework runtime references.
Serve the output through a small static server and run Playwright, Axe, and Lighthouse against the same artifact that will be deployed.