Use generateStaticParams for dynamic routes

Pre-render dynamic pages at build time instead of on every request to cut TTFB.

Code example

Copy, adapt, and ship.

Read the numbered lines, copy the complete snippet, then adjust the values for your project.

app/blog/[slug]/page.jsx

01// app/blog/[slug]/page.jsx02export async function generateStaticParams() {03  const posts = await getPosts();04 05  return posts.map((post) => ({06    slug: post.slug,07  }));08}09 10export default async function BlogPost({ params }) {11  const post = await getPostBySlug(params.slug);12  return <Article post={post} />;13}

Production-ready starting point13 lines · copy with one click

Why this matters

The production reason.

01
Dynamic routes are flexible, but if every slug waits for a server request before rendering, your first byte gets slower and crawlers see less stable output.
02
Use generateStaticParams when you already know the important slugs at build time: blog posts, product pages, docs, landing pages, and category archives.
03
Keep this paired with a sensible fallback strategy for content that changes often, so new pages can still appear without a full rebuild when your app needs that behavior.

Platform notes03

How it holds up outside a demo.

Next.jsUse this in App Router dynamic segments like app/blog/[slug]/page.jsx.
Sanity or CMSQuery only slug fields here, not the full document body.
VercelPair with revalidate or webhook-triggered deploys for fresh editorial content.