The plugin debt nobody budgets for
A WordPress site with forty plugins is a site with forty vendors, forty release schedules and forty chances that somebody else's Tuesday afternoon becomes your Tuesday night. Patchstack logged 11,334 new vulnerabilities across the WordPress ecosystem in 2025, up 42% on the year before, and 91% of them lived in plugins rather than in core. Core itself had six, all low priority. The CMS is not the problem. The forty things bolted to it are, and almost nobody puts them in a budget line.
Forty plugins is forty vendors you did not hire
The WordPress plugin directory lists over 72,000 free plugins, and that number is most of why WordPress won. You needed a booking form on Thursday, somebody had already written one, and it cost nothing. That was a real advantage and it still is. What the install screen does not show you is that each plugin runs as PHP inside your process, in the same global namespace as everything else. WordPress's own developer handbook tells plugin authors to prefix every function, class and global variable with at least four or five characters because, in its words, you are going to run into conflicts. That is the architecture being honest with you.
The maintenance arithmetic follows from that. Wordfence published 2,213 new vulnerabilities in the last quarter of 2025 alone, 658 of them cross site scripting and 611 missing authorization checks. At the close of that quarter 905 were still unpatched. Patchstack puts the full year figure at 46% of vulnerabilities reaching public disclosure with no fix available from the developer. You can be diligent, update weekly, and still spend half your exposure window waiting on someone who has moved on to a different project.
The speed matters more than the count. Patchstack measured a weighted median of five hours between a vulnerability going public and mass exploitation starting. Roughly half of high impact ones are attacked inside a day. A monthly maintenance window does not fit inside five hours, and neither does a person with a job.
Why the site gets slower every year
Performance decay on a plugin heavy site is not mysterious. Every active plugin registers hooks that fire on requests it has nothing to do with, enqueues its own CSS and JavaScript on pages that never use its features, and frequently adds its own rows to wp_options with autoload set. Ten plugins is tolerable. Forty means the server does forty plugins' worth of bootstrapping before it renders a paragraph of text, on every single request, and the caching plugin you installed to fix that is plugin forty-one.
Nobody decides to slow the site down. It happens one reasonable install at a time, and each one is genuinely justified. The trouble is that removing a plugin is much harder than adding one, because you cannot tell what it touched. Plugins write to the shared options table, add custom post types, filter content, and leave data behind on uninstall. Deactivating one to test a theory on a live site is not something most people will do on a Friday.
When we moved Stay World Class off Webflow and Xano to Next.js, NestJS and Supabase, Lighthouse went from 55.91 to 91 out of 100 and LCP dropped 77%. Almost none of that came from clever optimization. It came from the page no longer loading code that belonged to somebody else's feature. A 4-stage ETL mapped the legacy IDs onto PostgreSQL UUIDs so nothing was lost in the move.
What the real cost looks like in a line item
Most budgets carry hosting and a few premium licences, then stop. The costs that actually bite live elsewhere: someone has to read the changelogs, run updates on staging, notice when a plugin gets sold to a new owner, and respond inside five hours when a disclosure lands. If nobody owns that, the site is not maintained, it is just currently working. That distinction only becomes visible once.
Patchstack also found that in a large pentest of popular hosting providers, only 26% of vulnerability attacks were blocked at the network and server layer. The firewall in your hosting panel is doing less than the marketing page suggests, because these exploits mostly look like ordinary authenticated traffic. Broken access control was the most exploited category last year for exactly that reason.
Custom code has bugs too, and pretending otherwise would be dishonest. The difference is ownership. When the checkout on an application you own breaks, you read your own code, write a failing test, and ship a fix in an afternoon. When a plugin breaks it, you file a support ticket and wait, and 46% of the time there is nothing to wait for.
When staying on WordPress is the right answer
If your site is a blog, a brochure, or a small shop running six well maintained plugins from vendors who ship security updates, leaving would be a waste of money. WordPress is excellent at publishing, the editorial workflow is better than most things you would build, and six plugins is a surface area a person can actually hold in their head. Add a managed host that patches for you and you have a sensible setup.
The same goes if the plugins are the product. Some businesses run on WooCommerce with deep customisation and a developer who knows every extension in the stack. That is a real engineering practice, just one built on WordPress, and rebuilding it elsewhere buys very little.
The case for moving gets strong at a specific point: when the logic your business depends on lives inside plugins you cannot test, when the plugin count keeps climbing because each new requirement needs another one, and when a security disclosure means waiting on a stranger. Until you hit that, updating on schedule and keeping the list short is the cheaper answer, and there is no reason to feel bad about it.
