Laurie Ruettimann is an author, speaker, and podcaster who runs her business from laurieruettimann.com. Her WordPress site had been running for years, built on WPBakery Page Builder and hosted on WP Engine. It worked. Mostly. But under the hood, things had been quietly getting worse for a long time, and the site’s performance was starting to reflect that.
She reached out to me in mid-October 2025. About two weeks later, everything was resolved.
What Was Going On
Laurie’s site had the kind of problems I’ve seen time and again with long-running legacy WordPress sites. They pass between developers who have tools they prefer to use. Some new interesting-looking plugin or service comes along, gets installed, and gets forgotten about. It’s not anybody’s fault that this happens, per se. It’s just the nature of WordPress and the ease of installing plugins and themes and block libraries and whatever else is out there. Over enough years, without ongoing maintenance keeping things in check, it all adds up.
Here’s what I found when I got under the hood:
Redundant and risky plugins. The site was running three separate form solutions at the same time: Gravity Forms, Jetpack Forms, and Contact Form 7. Only Gravity Forms was actually needed. The other two were just sitting there, adding overhead and complexity for no reason. On top of that, Slider Revolution and Auto-hyperlink URLs were both active with known security issues. A plugin called Brave Conversion Engine seemed to be doing nothing useful. Go Pricing and Jetpack Boost were along for the ride too. Every one of these was loading code on every page load, whether it was doing anything or not.
A caching plugin that was making things worse. The site’s CSS and JavaScript minification plugin was hammering the database with 29 cache lookups per page load and logging 1.52 MB of CSS data every time. The logging alone was generating dozens of slow INSERT queries. This is the kind of thing that’s easy to miss because the plugin is supposed to be helping. In this case, it was one of the biggest performance problems on the site.
Database bloat and missing indexes. Orphaned metadata, stale revisions, transient data that had overstayed its welcome. The database had never been properly indexed for the queries WordPress was actually running against it, which meant every page load was doing more work than it needed to. On top of that, 34+ cron jobs were scheduled, most of them left over from plugins that were no longer active.
Uncompressed images with no modern format support. Every image on the site was being served at its original size in its original format. No compression, no WebP, no optimization pipeline of any kind. For a content-rich site like Laurie’s, that adds up to a lot of unnecessary bandwidth on every visit.
WPBakery loading everything. The page builder was configured to load assets for roughly 140 elements. The site was actually using about 50 of them. That meant a lot of CSS and JavaScript being downloaded on every page for features that weren’t being used anywhere.
A hero image that technically didn’t exist. This was an interesting one. The main hero image on the homepage was being served as a CSS background-image instead of a proper <img> tag. The browser had a preload hint telling it to fetch the image early, but there was nothing in the DOM to actually display it. The browser was doing the right thing with bad instructions. This turned out to be the single biggest factor in the site’s poor Largest Contentful Paint score.
What I Did
I spent about eight days working through the full list in between other client projects. The approach was pretty straightforward: remove what shouldn’t be there, replace what’s underperforming, and optimize what’s left.
The security risks came out first. Slider Revolution and Auto-hyperlink URLs both had known security issues and were the top priority. Brave Conversion Engine, Go Pricing, and Jetpack Boost weren’t pulling their weight either, so those went too. Fewer plugins means less code running on every page, fewer things to keep updated, and a smaller attack surface overall.
Then I replaced the plugins that weren’t doing their jobs well. The minification plugin got swapped for WP-Optimize, which handled caching and optimization without beating up the database. Simple 301 Redirects got replaced with Safe Redirect Manager. And WPCode Lite, which was really only there for a Facebook pixel and Google site verification tag, got replaced with a lightweight custom plugin that did those two things and nothing else.
The form situation needed untangling. Three form plugins running simultaneously is a mess, especially when only one of them is actually handling submissions. I migrated everything to Gravity Forms, archived the old forms that were no longer relevant, confirmed that a handful of stale submissions were spam and could be safely deleted, and verified all six active forms were working correctly. Then Jetpack Forms and Contact Form 7 came out for good.
Images got the full treatment. I losslessly compressed every existing image on the site and installed a plugin to automatically serve next-gen formats (WebP) for all uploads going forward. This is one of those things that makes a noticeable difference immediately, especially on image-heavy pages.
The database got a proper cleanup. I cleared out orphaned data, old revisions, and transients that were no longer needed, then added proper indexes to the database tables so WordPress could run its queries more efficiently. I also cleaned up the cron schedule, removing jobs that were tied to plugins we’d already removed.
WPBakery got trimmed down significantly. I disabled roughly 90 unused page builder elements, which meant the site stopped loading CSS and JavaScript for features it was never going to use. Same visual result for visitors, significantly less code being shipped to the browser.
And the hero image got fixed properly. I converted the CSS background-image to a real <img> tag so the browser could actually find it, render it, and count it toward Largest Contentful Paint. This was the single biggest LCP win of the whole project.
The Results
I ran speed tests before and after the work. The numbers spoke for themselves.
| Metric | Before | After | Improvement |
|---|---|---|---|
| Initial Connection | ~500ms | ~100ms | 81% faster |
| First Visual Paint | 2.5s | 0.6s | 76% faster |
| Largest Contentful Paint | 4.7s | 1.3s | 72% faster |
| Speed Index | 3.9s | 1.7s | 55% faster |
The whole engagement took about two weeks from first contact to final documentation. Around eight of those days were actual hands-on work, done in roughly two hour sprints each day. The rest was coordinating with Laurie to make sure I was making changes at times that wouldn’t cause issues for her visitors. I kept her in the loop throughout and documented every change so she’d have a clear record of what happened and why.
The work ended up running a bit longer than what I originally quoted. I wanted to be mindful of Laurie’s budget, so I didn’t nickel and dime her for the overage. The site needed the work and I wanted to do it right.
In Laurie’s Words
Jason fixed my WordPress site’s performance issues and then some. Load times dropped by more than half. He cleaned up years of problems I didn’t even know were there and kept me informed throughout the entire process. Thorough, honest, and explains what he’s doing in a way that actually makes sense.
Laurie Ruettimann, Author, Speaker & Podcaster
Got a Similar Situation?
If your WordPress site has been accumulating technical debt for years and you’re not sure where to start, that’s exactly the kind of thing I sort out. Book a free 30-minute consultation and we’ll figure out what’s going on.