When a website is slow, most owners assume they need a more expensive hosting plan, a caching plugin, or a full redesign. Sometimes that is true. But this year we took a WordPress site that was taking about 1.75 seconds just to generate each page and got it down to about half a second, and we did not upgrade the hosting or redesign anything. Everything we fixed was already there, quietly misconfigured.
Here is what we found, because the same problems are hiding on a lot of small business websites.
The Database Was Running on a Twenty-Year-Old Engine
WordPress stores everything (pages, products, orders, settings) in a MySQL database, and each table in that database uses a storage engine. The old engine, MyISAM, locks an entire table every time anything writes to it. The modern engine, InnoDB, locks only the row being changed and recovers gracefully from crashes. New installs have used InnoDB by default for years, but older sites, and sites that have been migrated between hosts a few times, often carry a mix of both without anyone knowing.
On the site in question, and in fact across every database on the same server, we found dozens of tables still on MyISAM. Converting them is a routine, low-risk operation (with a backup first, always), and on a busy site the difference is noticeable, especially for stores where orders and page views are writing to the database at the same time.
The PHP Cache Was Full
Modern PHP keeps a compiled copy of your site’s code in memory, called OPcache, so it does not have to re-read and re-compile every file on every single visit. This works beautifully until the cache fills up. When that happens, PHP starts throwing out compiled code and redoing the work constantly, and every site on the server gets slower. Nothing crashes and no errors appear, which is exactly why nobody notices.
That is what we found here: the cache was saturated, and simply giving it enough memory produced an immediate, measurable improvement across every site on the server. If your host manages this for you, the takeaway is simpler: when a previously fine site gets gradually slower and the usual suspects check out clean, ask your host about OPcache usage.
A Server Setting Was Killing Workers Too Early
The third find was a single configuration value that told the server to recycle each PHP worker process after only 20 requests. Recycling workers is normal and healthy, but doing it that aggressively means the server spends a meaningful chunk of its time starting fresh processes instead of serving pages. Raising the value to a sensible number was a one-line change.
The Pattern Behind All Three
Notice what these have in common: none of them were caused by the website itself. The theme was fine. The plugins were fine. The content was fine. All three problems lived a layer below, in the database and server configuration, where normal website checkups never look.
This is why we are skeptical when the first answer to a slow site is “install a caching plugin” or “upgrade your plan.” Caching hides slowness; it does not cure it. And a bigger server running the same misconfiguration is just a more expensive way to have the same problem.
What You Can Do
If your site feels slower than it used to, ask your hosting company or IT provider three specific questions: Are any of my database tables still on MyISAM? Is OPcache hitting its memory limit? And are the PHP worker settings sensible for my traffic? Those three answers cost nothing to get and will tell you more than most speed-test screenshots.
And if the answers you get back are vague, that is a signal too. We do this kind of under-the-hood review for our clients regularly, so if your site needs one, let us know.