I removed JetPack Boost from my WordPress installation last week. Not because it wasn’t working—it was—but because I’d spent the previous month properly configuring Apache, and suddenly most of what the plugin did was either redundant or actively conflicting with what my server was already handling. This is the problem I have with WordPress performance plugins: they assume your server is doing nothing. They’re built for shared hosting environments where you have no access to Apache or Nginx configuration, where PHP-FPM isn’t tuned, where Redis or Memcached aren’t even options. In those environments, plugins like JetPack Boost, WP Rocket, or W3 Total Cache make perfect sense. They’re compensating for infrastructure you can’t control. But I’m on a self-hosted WordPress installation on a Digital Ocean Ubuntu Linux VPS. Once you’ve got mod_cache_disk working, Redis handling object caching, Brotli compressing everything, and HTTP/2 enabled with proper headers, suddenly you’re running two caching layers that don’t know about each other. Your plugin is trying to cache pages that Apache already cached. It’s minifying HTML that Brotli will compress more efficiently anyway. It’s adding complexity where you need clarity. The first sign something was wrong came when I checked response headers. I was seeing cache hits from Apache, but JetPack Boost was still generating its own cached files. Two cache layers, both doing roughly the same work, neither aware of the other. The redundancy wasn’t just inelegant—it was slowing things down. When your server infrastructure is solid, the performance work that remains is almost entirely frontend optimisation. You’re no longer worried about page caching or compression—those are solved problems. What you need is CSS and JavaScript minification, concatenation, and intelligent loading. You need image optimisation. You need to prevent render-blocking resources and eliminate unnecessary HTTP requests. This is where most WordPress caching plugins become overkill. WP Rocket, for instance, is excellent—genuinely one of the best WordPress plugins ever written. But on a properly configured VPS, you’re paying for features you’ve already implemented at the server level. Page caching? Already handled. Gzip compression? Brotli does it better. Browser caching rules? Apache’s mod_expires has that covered. What you actually need are plugins that focus on the application layer without trying to replace your infrastructure. Autoptimize turned out to be exactly what I needed. It handles CSS and JavaScript minification and aggregation without touching anything else. It doesn’t try to implement its own caching layer. It doesn’t attempt to write rewrite rules to your .htaccess file. It generates optimised static files and lets Apache serve them with the caching and compression rules you’ve already configured. The configuration is straightforward if you understand what your server is already doing. Enable JavaScript optimisation and aggregation, but leave inline JavaScript alone—aggregating inline scripts breaks more things than it fixes. Enable CSS optimisation and aggregation, including inline CSS, because that’s generally safer. Disable HTML minification entirely because your server handles compression more efficiently than any PHP-based minifier ever could. The lazy loading feature works well, though you need to exclude above-the-fold images. Your site logo, hero images, anything visible before scrolling—add those to the exclusion list. Otherwise you’re trading a small performance gain for a visible loading delay on the most important visual elements of your page. I also enabled Google Fonts removal. That’s partially a privacy decision and partially performance—every external font request is another DNS lookup, another connection, another potential point of failure. If you need custom typography, serve the fonts yourself and let Apache cache them with everything else. This is equally important. Don’t install W3 Total Cache or WP Super Cache or any other full caching plugin. They will conflict with mod_cache_disk. They’ll create their own caching directories, write their own rewrite rules, and generally make a mess of your carefully configured Apache setup. Don’t install LiteSpeed Cache if you’re running Apache. It’s an excellent plugin, genuinely impressive, but it’s built for LiteSpeed web server. The name isn’t metaphorical. Don’t install any plugin that promises to optimise your database unless you know exactly what it’s doing. I run Advanced Database Cleaner Pro, but I spent time understanding what it cleans and when. Random database optimisation plugins love to delete post revisions and transients that other plugins might depend on. That’s how you create subtle, hard-to-debug problems that only surface weeks later. The one area where server configuration can’t help much is image optimisation. Apache can serve images efficiently, but it can’t retroactively compress a 5MB PNG someone uploaded three years ago. This is where workflow matters more than plugins. I handle image optimisation upstream, exporting web-optimised images directly from Adobe Lightroom to WordPress. The images arrive already compressed, already sized appropriately, already in the correct format. No plugin needs to process them after upload because the work is done before they reach the server. This is faster than any server-side optimisation plugin and gives me more control over the final output. The trade-off is discipline. You have to remember to use the export preset. You can’t rely on a plugin to catch oversized images after the fact. But the payoff is predictable file sizes and no server resources spent recompressing images that should have been optimised before upload. I didn’t run Lighthouse. I probably should have, but I also know what it would tell me. The performance score would be somewhere between 85 and 95. Largest Contentful Paint would be fine. Cumulative Layout Shift would probably flag something about font loading. First Contentful Paint would be good but not great because HTTP/2 server push isn’t configured yet and I’m not convinced it’s worth the complexity. These tools are useful when you don’t know what’s wrong. When you’ve methodically configured every layer of the stack, you generally know where the remaining problems are. The value of Lighthouse is in identifying issues you overlooked. The cost is the time spent installing Chrome on a headless VPS just to generate a report that mostly confirms what you already knew. What I did instead was simpler: visited the site logged out, opened browser DevTools, watched the network tab, and looked for anything obviously wrong. Were CSS and JavaScript files concatenated? Yes. Were they cached properly? Yes. Were images lazy-loading? Yes. Were there any console errors? No. Good enough. WordPress performance optimisation has become an industry of its own, complete with premium plugins that cost $200 a year and promise dramatic improvements. Most of it is solving problems that proper server configuration already handles. If you’re on shared hosting with no server access, those plugins are valuable—possibly essential. If you’ve got a VPS and you’re willing to learn Apache or Nginx configuration, they’re mostly redundant. The exception is frontend optimisation. Minifying and concatenating CSS and JavaScript, optimising images, implementing lazy loading—these are application-layer concerns that your web server can’t handle. These are the things plugins like Autoptimize do well. Everything else—caching, compression, HTTP/2, TLS configuration—those belong in your server config. Once they’re there, WordPress performance plugins mostly get in the way. ### Like this: Like Loading... Technology Apache Optimization Autoptimize Configuration Frontend Optimization Image Optimization Information Security JetPack Boost Alternative Plugin Selection Redis Object Cache Server Administration Server Configuration Server-Level Caching Technology VPS Management VPS Performance Tuning Web Development WordPress WordPress Performance WordPress Plugin Selection

After properly configuring Apache with Redis and Brotli compression, I realised JetPack Boost was doing more harm than good.

If you’ve ever felt like your website or application is moving slower than it should, you’re not...