Someone—probably your boss—thought switching from managed WordPress hosting to a shared server would “save money.” Now everything’s broken. Pages 503 randomly, the admin panels hang, and the whole site is crawling now. You’ve tried disabling plugins, clearing caches, even reinstalling WordPress—nothing helps, it just breaks things worse. The boss refuses to move back to a managed host—he won’t admit he was wrong—Instead, he wants it “fixed at root,” whatever that means, and you’re panicking. 

So—what would I do?

We’re going to have to squeeze as much performance as we can out of this situation as we can… 

First, we’re going to look at PHP-FPM settings and tune pm.max_children, pm.start_servers and match that up with the RAM available to us. Maybe in the CPanel we have access to these settings-we’d tweak them the best we can. We’d raise memory_limit and max_execution_time and max_input_time if we can—hosts usually set these way to low because they expect noobs to not notice. We’d verify and confirm Opcache configuration, and try to enable it—if supported. We wouldn’t have access to this kind of stuff, but maybe we find that we don’t have access to php.ini but we find out the system respects .user.ini FTW! Maybe I’m talking with support on your behalf…either way we’re going to do what we can! Shared host default are horrendous—but you can often work with them to change these.

Now that we’ve done as much as we could on the server-configuration side, now for the hard part: reducing bloat! All too often this is always the problem. Bloat can be made to run on managed hosts, but as soon as you touch a shared host—it’s too much.

But let’s say the main issue is all the different page-builders you used to build the site—don’t worry, I’m not here to judge—we all do it. The problem is you have thousands of posts and pages dating back over the years and you don’t know what page-builder you used where. And you dread the idea of manually converting all that content yourself. If your boss is serious about not moving back to a decent managed host, we might have to start getting really creative… 

For example, what I had to do with a client in the past: We decided on a cutoff date for content that was older than that and decided to freeze the content entirely. I had to build a PHP-CLI tool we could run on the server that would go over posts older than that date and store the result of the_content in the database. That wasn’t as hard as it was to also archive the CSS and JavaScript being loaded on the page too—those had to get saved (frozen) on-disk. At the end of it all, old post content was basically frozen (yes, you couldn’t even edit these old posts) in time. This meant all the older posts were loading faster now (since the content was basically cached on-disk—page-builders weren’t running). This allowed us to eventually disable all the page-builder plugins, and all future content would be editing through the normal WordPress workflow (Gutenberg) which was better for them anyways—all that old content needed those page-builders because Gutenberg didn’t exist yet. 

Now the site should be running better on the lower-tier hosting platform (they got to actually save money after-all), but we had to get really creative about it. There’s tons more we could do—but it’s almost always things like page-builders that don’t work well in low-resource environments. And other than your boss feeling vindicated—we’re all happier.