Shipping on the edge with Next.js 14

A blog that renders fast is a blog that gets read. Next.js 14 gives you several ways to render, and the defaults are quietly excellent — but only if you understand which one you are using.

Static by default

Every route in the app directory is statically rendered unless you opt out. That is the right default for a blog. The one thing you must remember is to enumerate your paths.

import { getPostSlugs } from '@/lib/posts';
 
export async function generateStaticParams() {
  return getPostSlugs().map((slug) => ({ slug }));
}
 
export default function Page({ params }: { params: { slug: string } }) {
  // rendered at build time, one HTML file per slug
  return <Article slug={params.slug} />;
}

The generateStaticParams call is what turns a dynamic route into a folder of static HTML. Forget it and you get on-demand rendering — fine for an app, wasteful for a blog.

When to reach for the edge

Static files already serve from the nearest CDN PoP. Edge rendering earns its keep when your page needs a little dynamism — a draft preview, a per-request theme, a footer with the current build hash.

export const runtime = 'edge';
export const revalidate = 3600; // refresh background

Use it when the cost of going fully static is a stale page. Do not use it to feel modern.

The checklist I run before every deploy

• generateStaticParams returns every slug.
• No accidental fetch with dynamic cache on a static page.
• Images are .webp, sized, and lazy below the fold.
• Fonts use next/font or display: swap.

Run that list and your Lighthouse score stops being a surprise.