Edge runtime for headless WordPress: which routes win, which lose

“Move everything to the edge” is bad advice. Edge runtime has cold start advantages but Node.js advantages for anything that does heavy work or talks to a database close to it. Here is the routing pattern we ship now for headless WordPress on Next.js running on a Hetzner / Dokploy container.

Run at the edge

• Static rendering of cached pages. ISR-cached HTML serves from the CDN or reverse proxy with no compute. This is the default win.
• Geo-aware redirects. Language, currency, region detection. Move it to Cloudflare Workers or the Traefik edge and the response is one round-trip shorter.
• Webhook receivers. Lightweight POST handlers that flush cache, push to a queue, or fire-and-forget. No need for heavy Node.

Stay on Node

• The actual WP REST call. If WP is in one region, edge calls from 12 regions all hop back to it. Pin the API route to a Node container close to WP.
• Image transforms or heavy parsing. Edge runtimes have stricter limits on CPU, memory, and bundle size.
• Long-running tasks. Most edge runtimes cap timeout at 25-30 seconds. A complex AI call or PDF generation hits that wall.

The result

On one client site (200k pageviews/mo), moving cached pages to a Cloudflare edge cache in front of our Hetzner container dropped p75 TTFB from 480ms to 60ms in Europe and Asia, with US p75 unchanged (origin is in Falkenstein). The contact-form API stayed on the origin because it talks to WP, Mailgun and Slack in sequence; we did not want to multiply the latency.

If you are running headless WordPress and weighing an edge migration, our web development team has a one-week audit that maps each route to its right runtime. Get in touch.