Web Development

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

Edge functions are not faster for everything. After moving 4 client headless-WP sites to the edge selectively, here is the routing decision we landed on.

Updated 2 min read

“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 + Vercel.

Run at the edge#

  • Static rendering of cached pages. ISR-cached HTML serves from the edge with no compute. This is the default win.
  • Geo-aware redirects. Language, currency, region detection. The edge has the user’s IP without a round-trip.
  • Webhook receivers. Lightweight POST handlers that flush cache, push to a queue, or fire-and-forget. No need for 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 region close to WP.
  • Image transforms or heavy parsing. Edge runtimes have stricter limits on CPU, memory, and bundle size.
  • Long-running tasks. Edge runtime caps timeout at 25 seconds. A complex AI call or PDF generation hits that wall.

The result#

On one client site (200k pageviews/mo), moving cached pages to the edge dropped p75 TTFB from 480ms to 60ms in Europe and Asia, with US p75 unchanged (WP is in iad1). The contact-form API stayed on Node 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.

More from Web Development