{"id":98025,"date":"2026-10-06T12:38:00","date_gmt":"2026-10-06T16:38:00","guid":{"rendered":"https:\/\/overcentral.com\/en\/?p=98025"},"modified":"2026-09-29T07:55:39","modified_gmt":"2026-09-29T11:55:39","slug":"emdash-vs-wordpress-high-traffic-98025","status":"publish","type":"post","link":"https:\/\/overcentral.com\/en\/emdash-vs-wordpress-high-traffic-98025\/","title":{"rendered":"EmDash vs WordPress: The Non-Obvious Truth About High Traffic"},"content":{"rendered":"

You have 500,000 visitors hitting your site in the next hour. WordPress<\/a> might crash. EmDash might bankrupt you. Both outcomes are real, and neither is obvious from a dashboard demo.<\/p>\n

The typical comparison stops at “WordPress is old and slow, EmDash is modern and fast.” That tells you nothing about what happens when traffic actually arrives. The difference isn’t speed. It’s how each platform manages cost<\/em> and failure<\/em> under load.<\/p>\n

The Architecture Divergence That Matters<\/h2>\n

WordPress uses a monolithic PHP process. When a visitor lands on your site, Apache or Nginx spins up a PHP worker, loads the entire WordPress core, executes all active plugin code, queries MySQL, renders HTML, and sends it back. Every request is a full stack call. This is fine for 10 requests per second<\/a>. At 1000 requests per second, you need more servers, more PHP workers, and a caching layer that prevents WordPress from actually running WordPress.<\/p>\n

EmDash is serverless. Each request spins up a V8 isolate on Cloudflare’s edge. That isolate runs Astro-compiled code, queries D1 (SQLite at the edge), serves static assets from R2, and disappears. No persistent process. No shared state. No server to maintain.<\/p>\n

Here’s the comparison in concrete terms:<\/p>\n\n\n\n\n\n\n\n\n\n\n
Scenario<\/th>\nWordPress<\/th>\nEmDash<\/th>\n<\/tr>\n<\/thead>\n
Cold start (first request after idle)<\/td>\n200-500ms (PHP + MySQL connection)<\/td>\n5-15ms (V8 isolate spin-up)<\/td>\n<\/tr>\n
Sustained 1000 req\/s<\/td>\nRequires 4-8 mid-range servers + Redis + CDN<\/td>\nHandles natively via Cloudflare<\/a> edge, no manual scaling<\/td>\n<\/tr>\n
Cost at 10M monthly visits<\/td>\n$200-800\/month (managed hosting + plugins)<\/td>\n$5-50\/month (Cloudflare paid plan + usage)<\/td>\n<\/tr>\n
Cost at 100M monthly visits<\/td>\n$2000-8000\/month (scaled infrastructure)<\/td>\n$500-2000\/month (primarily bandwidth + compute)<\/td>\n<\/tr>\n
Traffic spike protection<\/td>\nThrottling, crash, or surcharge invoice<\/td>\nNo built-in spending cap; potential $13k+ bill<\/td>\n<\/tr>\n
Debugging production issues<\/td>\nSSH into server, check error logs<\/td>\nCloudflare dashboard + Workers logs (less granular)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The table shows the trade-off clearly: EmDash wins on baseline cost and scaling ease, but loses on cost predictability and debugging depth.<\/p>\n

Where WordPress Actually Fails Under Load<\/h2>\n

WordPress’s scaling problem isn’t PHP itself. Modern PHP 8+ with OPcache is fast enough. The problem is the plugin tax<\/em>. Every plugin adds its own database queries, hooks, and filters. A typical WordPress site with 15 plugins might execute 40-60 SQL queries per page load. With 200 visitors per second, that’s 8000-12,000 queries per second. MySQL can handle that with proper indexing and a read replica, but most managed hosts don’t give you that for $30\/month.<\/p>\n

The real bottleneck: WordPress’s architecture forces a round-trip to the database for every uncached request. Even with Redis or Varnish, cache invalidation becomes a nightmare when plugins modify content dynamically. You end up caching less than you think.<\/p>\n

EmDash’s Scaling Gambit<\/h2>\n

EmDash avoids the plugin tax because plugins run in isolated V8 workers. Each plugin’s code executes only when its hooks fire, not on every page load. The Astro framework pre-renders static pages at build time. Dynamic pages (search results, user-specific content) still require server-side rendering, but Astro’s partial hydration keeps the payload small.<\/p>\n

But here’s the non-obvious<\/a> catch: EmDash’s scaling depends entirely on Cloudflare’s infrastructure. You don’t control the database sharding, the cache warming, or the edge distribution. When D1 hits its concurrent connection limit (which is real at scale), your site returns 503 errors. Cloudflare’s team can fix it, but you can’t.<\/p>\n

The $13,000 Nightmare<\/h2>\n

The most dangerous feature of EmDash for high-traffic sites is the billing model. WordPress hosting is flat-rate. You pay $200\/month whether you get 100 visitors or 100,000. EmDash is per-request. A DDoS attack that generates 10 million requests in a day could cost you $3000 on the $5 plan. A sustained attack over a week could exceed $13,000.<\/p>\n

Cloudflare offers no built-in spending cap. You can set CPU time limits per request and rate-limiting via WAF, but those are leaky abstractions. A distributed attack from thousands of IPs bypasses rate-limiting. The only real protection is a third-party monitoring service that cuts off your Cloudflare API key when spending exceeds a threshold \u2014 and that requires manual setup and ongoing maintenance.<\/p>\n

WordPress hosting protects you from surprise bills. EmDash does not.<\/p>\n

Plugin and Theme Performance<\/h2>\n

WordPress plugins run in the same process. A poorly coded plugin can slow down every page. You’ve seen it: a contact form plugin that runs a database query on every admin page load. You can’t isolate it.<\/p>\n

EmDash plugins run in sandboxed workers. A bad plugin can’t crash your site. But it can still be slow \u2014 the V8 isolate has limited CPU allocation. Complex plugins (e.g., an AI content generator) may hit Cloudflare’s CPU time limit and fail silently. Debugging that is harder than in WordPress because you don’t have direct access to the worker logs.<\/p>\n

Caching: The Hidden Differentiator<\/h2>\n

WordPress relies on page caching plugins (WP Rocket, W3 Total Cache) to serve static HTML. These work well, but they add complexity. Cache clearing on content update often misses variations, leading to stale content or cache stampedes.<\/p>\n

EmDash uses Cloudflare’s global CDN by default. Static pages are cached at 330+ edge locations. Dynamic pages use Astro’s route caching with D1. The cache invalidation is automatic and atomic \u2014 when you update a post, the CDN purges that URL instantly. This is genuinely better than WordPress’s cache ecosystem for most sites.<\/p>\n

But for sites with heavy personalized content (member areas, e-commerce carts), EmDash’s caching advantage disappears. You’re back to server-side rendering on each request, which is slower than WordPress with Varnish and Redis.<\/p>\n

Real-World Scenarios<\/h2>\n

Scenario 1: Viral blog post.<\/strong> A 5000-word article hits Hacker News front page. 200,000 visitors in 6 hours.<\/p>\n