MyPhotoAI · pSEO case study

ISR versus static export on a pSEO surface: the trade-off line

Next.js gives you two delivery modes for a pSEO surface: full static export at build time, or incremental static regeneration at request time. They look similar from the outside; the trade-off line runs through deploy time, first-request latency, and cache-invalidation complexity. This leaf documents the line and the migration sketch in either direction.

By AlkenaCode engineering team

We ship programmatic SEO surfaces, AI-driven receptionists, and case-study sites for Kenyan SMEs and overseas clients. Every claim on this page traces back to shipping work, not speculation. The audit tool on /audit is the same software we use to evaluate prospective engagements.

Authors of the myphotoai.alkenacode.dev pSEO surface itself. Source code is open at github.com/Kiragu-Maina/alkenacode-family. Production deployments include agents.alkenacode.dev and home.alkenacode.dev.

Last updated:

We have shipped both modes: this surface is static export, the 300-leaf engagement referenced in the build-times leaf is ISR. The cold-request latency numbers in section one are from production traces on the ISR surface.

ISR versus static export on a pSEO surface: the trade-off line

The trade-off across four dimensions

Deploy time: static export rebuilds every leaf on every deploy; ISR rebuilds nothing on deploy, leaves regenerate on first request. Under five hundred leaves, the static rebuild is fast enough to ignore; past five hundred, deploy time bites. First-request latency: static export serves from CDN cache, low double-digit milliseconds; ISR cold-leaf first request is eight hundred to one and a half seconds while the page renders. Cache invalidation: static needs no invalidation, just redeploy; ISR uses revalidatePath or revalidate-by-time, which adds operational surface.

The leaf-count threshold and the latency budget

Our threshold for cutover is five hundred leaves or a two-minute cold-build, whichever comes first. Below that, static export wins on operational simplicity. Above it, ISR wins on deploy economics. The first-request latency penalty on ISR is real but invisible to the long tail: a leaf with two impressions per month sees its first-request latency once and then serves from edge cache forever after. The penalty matters for trending leaves that get a burst of traffic on a cold cache; for those, manual pre-warming via revalidatePath on deploy is the fix.

Migration sketch in either direction

Static-to-ISR migration is straightforward: remove output: export from next.config.js, add revalidate: 86400 to the page export, deploy. The first deploy will still build all leaves statically; subsequent deploys will rely on ISR. ISR-to-static migration is also straightforward if your leaf count has shrunk: re-enable output: export, redeploy. The pitfall in either direction is the sitemap: static export emits the full URL list at build time; ISR emits whatever the slug manifest holds. Keep the sitemap source as the manifest, not the page set, to avoid drift.

src/app/p/[slug]/page.tsxtsx
import { SLUGS } from "../../../../content/slugs";

export const dynamicParams = false;

export function generateStaticParams() {
  return SLUGS.map((s) => ({ slug: s.slug }));
}

export default function LeafPage({ params }: { params: { slug: string } }) {
  const leaf = SLUGS.find((s) => s.slug === params.slug);
  if (!leaf) notFound();
  // ... render the leaf
}
The leaf route's generateStaticParams reads the manifest at build time and tells Next.js which slugs to emit as static HTML.

Sources

Every claim on this page traces back to one of the verifiable sources below. Citations are publisher-stable; we avoid blog posts and other URLs that may not survive a year.

  1. Next.js docs: incremental static regeneration (Next.js)
  2. Next.js docs: output option (standalone, export) (Next.js)
  3. Next.js docs: App Router (Next.js)
  4. Next.js docs: revalidatePath (Next.js)
  5. Next.js docs: generateStaticParams (Next.js)
  6. Next.js docs: sitemap file convention (Next.js)
  7. MDN: HTTP caching (MDN)
  8. MDN: Cache-Control header (MDN)
  9. Cloudflare docs: how the cache works (Cloudflare)
  10. web.dev: Largest Contentful Paint (LCP) (web.dev)
Free site auditor

See how the pattern applies to your site

The auditor uses the same evidence bundle described above (robots, sitemap, page samples) and returns a structured opinion. No signup, no email required to see results.