Static vs Dynamic Sites: AI Rules for Each

Pre-Built at Deploy vs Rendered Per Request

Static sites: every page is generated as HTML during the build step. astro build or next build produces: HTML files for every route. The files: are deployed to a CDN. Every user request: is served from the CDN cache (no server computation). The content: is the same for every user until the next deploy. Frameworks: Astro (static-first), Next.js with generateStaticParams (static export), Hugo, 11ty. Static sites are: the fastest to serve (CDN-cached HTML), the cheapest to host (no server), and the most reliable (no server to crash).

Dynamic sites: every page is rendered on request. The server: runs code for each request, fetches data, renders HTML, and returns the response. The content: can be personalized per user, real-time fresh, and different on every request. Frameworks: Next.js with dynamic rendering (no cache), Remix (server-rendered by default), Express/Fastify APIs. Dynamic sites are: always fresh (no stale content), personalizable (different content per user), and more expensive (server computation per request).

Without rendering strategy rules: the AI generates dynamic server-side code in a static site project (fetching user-specific data in an Astro page that is pre-built at deploy), or generates static export patterns in a dynamic site (next export in a project that needs real-time data). The rendering strategy determines: when data is fetched (build time vs request time), how pages are cached (CDN forever vs short TTL), and which framework APIs the AI uses. One rule: prevents every rendering strategy mismatch.

Data Freshness: Build-Time vs Request-Time

Static data freshness: data is fetched at build time. If the blog post was updated 5 minutes after the last build: the site shows the old version until the next build. Freshness: depends on build frequency (build every hour = data is up to 1 hour stale). Mitigation: ISR (Incremental Static Regeneration) — pages regenerate after a TTL without a full rebuild. AI rule: 'Static: data fetched at build time. Content may be stale until next build. ISR: export const revalidate = 3600 for hourly refresh. Acceptable for: blogs, docs, marketing pages.'

Dynamic data freshness: data is fetched on every request. The page always shows: the current data. No staleness: the database is queried in real-time. Cost: every request hits the database and runs server code. Mitigation: cache dynamic responses with stale-while-revalidate headers (serve cached, refresh in background). AI rule: 'Dynamic: data fetched on every request. Always fresh. Use: Cache-Control: s-maxage=60, stale-while-revalidate=300 for content that can be briefly stale. Required for: user dashboards, real-time data, personalized content.'

The freshness rule prevents: the AI treating a static page as real-time (generating useEffect to refetch data that was already baked into the HTML at build time — the data is in the page, no need to refetch), or treating a dynamic page as static (caching user-specific content on the CDN — User A sees User B's dashboard). The rule tells the AI: which data is build-time (already in the HTML) and which is request-time (fetched fresh on every load).

• Static: data at build time, stale until rebuild. ISR: revalidate = N seconds for periodic refresh
• Dynamic: data on every request, always fresh. Cache: s-maxage + stale-while-revalidate for cost
• Static acceptable: blogs, docs, marketing. Dynamic required: dashboards, real-time, personalized
• ISR: the hybrid — static performance with periodic data refresh (no full rebuild needed)
• AI error: useEffect refetch on a static page (data already in HTML). CDN cache on personalized page

Build Pipelines: Generate All vs Render on Demand

Static build pipeline: the build step generates every page. astro build: reads content (Markdown, CMS API), generates HTML for every route, outputs a dist/ directory of static files. Build time: proportional to page count (1000 pages = longer build than 10 pages). Deploy: upload dist/ to CDN (Vercel, Netlify, Cloudflare Pages). CI: build on every commit, deploy the output. AI rule: 'Static: build generates all pages. astro build or next build --output export. Deploy: CDN. Build time: grows with page count. Optimize: incremental builds, parallel generation.'

Dynamic build pipeline: the build step compiles the application code but does not generate pages. next build (with dynamic routes): compiles React, bundles JS, but pages render at request time. Deploy: to a server (Vercel serverless, self-hosted Node.js, Docker container). The server: runs continuously, handling requests. CI: build and deploy the application, not the pages. AI rule: 'Dynamic: build compiles application. Pages render on request. Deploy: serverless or container. The server must be running to serve pages.'

The build pipeline rule prevents: the AI generating next export for a project with dynamic routes (static export cannot handle request-time data), deploying a dynamic Next.js app to a static CDN without a server (the pages need a runtime), or running astro build expecting it to produce a Node.js server (Astro static output is HTML files, not a server). The deployment target: depends on the rendering strategy. Static = CDN. Dynamic = server.

• Static: build generates all HTML pages. Deploy to CDN. No server needed
• Dynamic: build compiles app. Pages render on request. Needs running server or serverless
• Static deploy: CDN (Vercel static, Netlify, Cloudflare Pages). Free or cheap
• Dynamic deploy: serverless (Vercel, AWS Lambda) or container (Docker, ECS). Running server
• AI error: static export for dynamic routes (cannot). CDN-only for dynamic app (needs server)

ISR: The Hybrid Approach

Incremental Static Regeneration (ISR): pages are generated statically but regenerate after a TTL. In Next.js: export const revalidate = 3600 (the page is served from cache for 1 hour, then regenerated in the background on the next request). The first request after TTL: serves the stale page (fast), triggers a background regeneration, and the next request: gets the fresh page. ISR combines: static performance (CDN-cached most of the time) with dynamic freshness (data refreshes without a full rebuild).

ISR rule: "Use ISR for pages that: change periodically (blog posts, product pages, documentation — not real-time), benefit from CDN caching (high traffic, content does not change per user), and need eventual freshness (stale for seconds or minutes is acceptable). Set revalidate: 60 for frequently changing data (product prices), 3600 for slowly changing data (blog posts), 86400 for rarely changing data (documentation). On-demand ISR: revalidatePath('/blog/post-slug') after a CMS publish triggers immediate regeneration without waiting for the TTL."

The ISR rule tells the AI: which pages should be ISR (not all pages need it — user dashboards should be dynamic, not ISR), what TTL to set (the AI must know the data change frequency), and how to trigger on-demand revalidation (after a CMS update, the page should regenerate immediately, not wait for the TTL). ISR is: the most common rendering strategy for content sites in 2026 (blogs, e-commerce product pages, documentation). The AI should default to: ISR for content, dynamic for user-specific pages.

• ISR: static + periodic refresh. revalidate = N seconds. CDN-cached most of the time
• TTL by data: 60s (prices), 3600s (blog posts), 86400s (docs) — match change frequency
• On-demand: revalidatePath() after CMS publish for immediate refresh
• ISR for: content pages, product pages, docs. Dynamic for: dashboards, personalized, real-time
• 2026 default: ISR for content sites. Dynamic for user-specific pages. Static for docs/marketing

When to Choose Each Strategy

Choose static when: content changes rarely (documentation, marketing pages, personal blogs), the site has no user-specific content (every visitor sees the same pages), performance is critical (static = CDN latency only, no server computation), and cost matters (static hosting is free or nearly free). Astro: the best framework for static sites in 2026 (content-focused, zero JS by default, island architecture for interactive components).

Choose dynamic when: content is user-specific (dashboards, account pages, personalized feeds), data must be real-time (stock prices, live scores, chat messages), the page depends on the request (authentication state, geo-location, A/B test variant), or the site has too many pages for static generation (100,000+ product pages with frequent price changes = too slow to rebuild). Next.js dynamic rendering: the default for authenticated and personalized pages.

Choose ISR when: you want static performance with dynamic freshness (the best of both worlds), content changes periodically but not per-request (blog posts updated daily, product prices updated hourly), and you need CDN caching without stale-forever content. Next.js ISR with on-demand revalidation: the 2026 default for content-heavy sites. The AI rule: specifies which strategy each page type uses. Not every page in a project uses the same strategy — the rule maps: page type to rendering strategy.

• Static: docs, marketing, blogs. Rarely changing, no user-specific content. Astro or Next.js export
• Dynamic: dashboards, real-time, personalized. Always fresh, server-rendered per request
• ISR: content sites, product pages. Static speed + periodic freshness. Next.js revalidate
• Mixed: static for public, dynamic for auth, ISR for content — most projects use multiple strategies
• The rule maps: page type to strategy. Not every page uses the same rendering approach

Rendering Strategy Summary

Summary of static vs dynamic site AI rules.

• Static: build-time HTML, CDN-cached, stale until rebuild. Cheapest, fastest, simplest
• Dynamic: request-time rendering, always fresh, server required. Most flexible, highest cost
• ISR: static + periodic refresh. CDN-cached with TTL-based regeneration. Best of both for content
• Data: static = build-time (may be stale). Dynamic = request-time (always fresh). ISR = TTL-fresh
• Deploy: static = CDN only. Dynamic = server/serverless. ISR = serverless with CDN cache
• AI error: useEffect on static page (data already in HTML). CDN cache on personalized dynamic page
• 2026 default: ISR for content, dynamic for user-specific, static for docs/marketing
• Rule maps page type to strategy: one project often uses multiple rendering strategies