The most counterintuitive thing about EmDash\u2019s plugin architecture is that CPU limits are the feature that makes it performant. Not the sandbox. Not the V8 isolates. The hard cap on compute per invocation.<\/p>\n
Most developers hear \u201cCPU limit\u201d and think bottleneck. Throttling. Something that slows their code down. But in EmDash, that limit is precisely why a badly written plugin cannot drag your entire site into the mud. WordPress has no such safeguard. One loop that doesn\u2019t terminate in a plugin, and every page load on your site suffers. EmDash flips that entirely.<\/p>\n
EmDash CMS<\/a>, the open-source spiritual successor to WordPress built on Astro and Cloudflare Workers<\/a>, enforces a strict CPU budget per plugin invocation. Every plugin runs in its own dynamic worker \u2014 a V8 isolate that spins up in milliseconds, executes code, and vanishes. The worker gets a fixed amount of CPU time. Exceed it, and the invocation is terminated. Your site keeps running. Other plugins keep running. The core CMS stays untouched.<\/p>\n This isn\u2019t a bug. It\u2019s the architectural choice<\/a> that makes plugin isolation actually work in production.<\/p>\n In WordPress, every plugin shares the same PHP process. A single The fix in WordPress is to throw hardware at it: more CPU cores, opcache tuning, object caching. But that treats the symptom, not the cause. The architecture has no native mechanism to say \u201cthis plugin has done enough work for one request; stop it before it hurts the site.\u201d<\/p>\n WordPress plugin authors rarely think about CPU budgets because there is no budget. The server just runs until the script finishes or hits the global EmDash\u2019s dynamic workers operate differently. Each plugin declares its capabilities in a manifest \u2014 for example, The CPU limit is measured in milliseconds of actual compute time, not wall-clock time. I\/O operations like database reads or external API calls don\u2019t count toward the limit \u2014 only the time the CPU spends executing JavaScript. This distinction matters. A plugin that waits on a network response doesn\u2019t burn its budget. A plugin that iterates over a large array in a tight loop does.<\/p>\n Cloudflare\u2019s Workers have a standard CPU time limit of 10ms on the free plan and 30ms on the paid plan per invocation. EmDash plugins running on the paid dynamic workers plan inherit a similar constraint. That sounds small until you realize that most plugin operations \u2014 sending an email, updating a meta field, logging an event \u2014 complete in under a millisecond. The limit is generous enough for the vast majority of use cases.<\/p>\n But it\u2019s unforgiving for poorly structured code. A plugin that tries to process a 10,000-row CSV inside a hook will hit the limit and be terminated. The developer must either break the work into chunks (using multiple hook invocations or an external queue) or offload the heavy lifting to a dedicated service.<\/p>\n The counterintuitive result: because every plugin is capped, no single plugin can degrade the performance of the site. The core CMS and all other plugins operate in their own isolated workers with their own budgets. A runaway plugin in one worker has no effect on the worker serving your homepage.<\/p>\n Compare this to WordPress, where a slow plugin slows everything. EmDash\u2019s architecture decouples plugin execution from site rendering. The front end is served by Astro, which runs on the edge and never touches plugin code. Plugins only execute in response to specific events \u2014 saving a post, submitting a form \u2014 and those events are isolated.<\/p>\n This also means that plugin performance is predictable. You can benchmark a plugin in isolation and know exactly how much CPU it uses per invocation. No hidden cross-plugin interference. No \u201cit worked on staging but slows down in production because of 15 other plugins\u201d surprises.<\/p>\n The CPU limit isn\u2019t a problem for typical plugin tasks. Sending an email via SMTP takes 0.2ms of CPU. Updating a content field takes 0.1ms. Even parsing a moderate JSON payload stays under 1ms.<\/p>\n The trouble comes when plugins do work that should be done elsewhere. Resizing images, generating PDFs, running machine learning inference \u2014 these belong in a separate service, not inside a CMS hook. EmDash\u2019s architecture forces that separation. It\u2019s a constraint, but one that leads to a cleaner, more scalable system.<\/p>\n Plugins that need to do heavy lifting can use Cloudflare Queues or a separate worker to defer work. The hook only triggers the queue, and the actual processing happens in a background worker with its own (higher) CPU limit. This pattern is common in modern serverless architectures and EmDash supports it natively.<\/p>\n For developers accustomed to WordPress\u2019s anything-goes approach, this feels restrictive. But it\u2019s the same restriction that makes serverless reliable. You wouldn\u2019t run a 30-second image processing job inside a Lambda that serves HTTP requests. EmDash applies the same logic to plugins.<\/p>\n The CPU limit has a second-order effect: it incentivizes efficient code. Plugin authors cannot just throw CPU at a problem. They must think about algorithmic complexity, batch operations, and asynchronous processing. That produces higher-quality plugins overall.<\/p>\n WordPress\u2019s plugin ecosystem suffers from bloat because there\u2019s no cost to inefficiency. A plugin that loads a 2MB JavaScript library on every page works fine on a developer\u2019s local machine. On a shared host with 100 other plugins, it\u2019s a disaster. EmDash\u2019s CPU limits surface these problems early. If your plugin can\u2019t complete its work within the budget, it needs to be rewritten \u2014 not just on EmDash, but anywhere.<\/p>\n This also makes the ecosystem more secure. A CPU limit is a natural defense against denial-of-service attacks that exploit plugin code. An attacker who finds a vulnerability that causes infinite recursion in a plugin will hit the limit quickly, and the worker terminates. The rest of the site remains unaffected.<\/p>\n As AI agents<\/a> increasingly generate plugin code, the risk of runaway or inefficient code grows. A human developer might notice a missing termination condition. An AI<\/a> might not. EmDash\u2019s CPU limit acts as a safety net. Even if the AI produces a plugin with an infinite loop, the worker kills it after a few milliseconds. The site stays up.<\/p>\n Cloudflare\u2019s built-in MCP server and agent skills make it easy for AI to interact with EmDash, but the CPU limit ensures those interactions are bounded. An agent that asks the CMS to \u201cfind and update all posts with a certain tag\u201d will be limited in how much compute it can consume per request. The agent can paginate or chunk the work, but it cannot lock up the CMS.<\/p>\n This is the architectural thinking that WordPress lacks. EmDash isn\u2019t just a rewrite in TypeScript. It\u2019s a fundamental shift in how plugins interact with the system. CPU limits are the invisible hand that keeps everything fast.<\/p>\n The next time you hear someone complain that EmDash\u2019s worker CPU limits are too restrictive, ask them whether they\u2019d rather have a plugin that silently steals 500ms from every page load. The limit isn\u2019t the problem. It\u2019s the solution.<\/p>\n","protected":false},"excerpt":{"rendered":" The most counterintuitive thing about EmDash\u2019s plugin architecture is that CPU limits are the feature that makes it performant. Not the sandbox. Not the V8 isolates. The hard cap on compute per invocation. Most developers hear \u201cCPU limit\u201d and think bottleneck. Throttling. Something that slows their code down. But in EmDash, that limit is precisely […]<\/p>\n","protected":false},"author":7,"featured_media":100263,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/98074.png","fifu_image_alt":"EmDash\u2019s Worker CPU Limits: Why They Make Plugins Faster, Not Slower","footnotes":""},"categories":[31],"tags":[],"class_list":["post-98074","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/98074.png","fifu_image_alt":"EmDash\u2019s Worker CPU Limits: Why They Make Plugins Faster, Not Slower","_links":{"self":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/98074","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/comments?post=98074"}],"version-history":[{"count":0,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/98074\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media\/100263"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media?parent=98074"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/categories?post=98074"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/tags?post=98074"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}How WordPress Plugins Hog the Event Loop<\/h2>\n
while(true)<\/code>codecodecodecodecode inside a badly coded contact form plugin \u2014 or a legitimate plugin that just happens to do heavy image processing on the same request \u2014 blocks everything. Database queries queue up. Page generation times spike. The entire admin panel becomes unusable.<\/p>\nmax_execution_time<\/code>codecodecodecodecode. That approach worked when plugins were simple. Today, plugins bundle dependencies, run background tasks, and make external API calls \u2014 all inside the same process that serves your visitors.<\/p>\nEmDash\u2019s CPU Limit: A Surgical Scalpel<\/h2>\n
read content<\/code>codecodecodecodecode and send email<\/code>codecodecodecodecode. When a hook fires, the runtime spawns a fresh V8 isolate for that plugin, passes the relevant data, and lets it run.<\/p>\nWhy Limits Improve Performance for Everyone<\/h2>\n
The Practitioner Nuance: What Breaks and What Doesn\u2019t<\/h2>\n
What This Means for the Plugin Ecosystem<\/h2>\n
The Future: AI-Generated Plugins and CPU Guardrails<\/h2>\n