CHOOSING BETWEEN STATIC HTML EXPORTS AND DYNAMIC SERVER RENDERS ON EDGE HOSTS

Next.js offers two primary ways to deploy your application: Static HTML Export (output: "export") and Dynamic Server-Side Rendering (Edge/Node.js SSR). Choosing the wrong one can affect performance, hosting costs, and compiler complexity. Let's analyze both configurations for edge nodes.

Static HTML Exports (output: "export")

A static export compiles your pages into pure HTML, CSS, and JS files during the build phase.

• Pros: Can be hosted on any static provider (GitHub Pages, Netlify, Cloudflare Pages). Unmatched load times, cheap hosting, and resilient against traffic spikes.
• Cons: No API routes, no dynamic server-side middleware, and requires rebuilding to update content.

Dynamic Server-Side Rendering (SSR)

SSR renders pages on demand in response to incoming requests, often running on edge runtimes.

• Pros: Supports full dynamic database access, server-side auth, redirects, and custom API Route Handlers.
• Cons: Higher hosting latency, requires a Node.js server or serverless Edge runtime (like Cloudflare Workers).

Performance Comparison

Setting up Next-on-Pages Configurations

To deploy Next.js dynamic routing on Cloudflare Pages, you need to configure your route handlers to run on the Edge runtime rather than standard Node.js:

// src/app/api/waitlist/route.ts
export const runtime = "edge";

export async function POST(req: Request) {
  const data = await req.json();
  // Perform high-speed write to KV or Postgres
  return Response.json({ success: true });
}

If your application consists mostly of marketing pages, choose static exports. If you need dynamic elements (such as a dashboard or DB-backed waitlist), run as a serverless/edge app. Read about how we set up a dynamic rewrite proxy for our waitlist in Waitlist API Proxy configuration.

References & Citations

• Next.js Deployment Guide: Next.js Docs
• Jamstack Performance Metrics: Jamstack Organization
• Monorepo remote cache optimizations: Monorepo Caching Guide