I recently released another major update to WP Optimizer, focused less on adding more switches and more on improving the underlying performance architecture, server compatibility and production reliability.

You can check it out here:
https://wordpress.org/plugins/wp-optimizer/

WP Optimizer is a free, modular WordPress performance and maintenance plugin. The idea is still the same: provide caching, optimization, diagnostics and maintenance tools in one place, while letting you enable only the modules you actually need.

The latest release includes some fairly substantial internal changes.

Layered cache architecture

The internal cache system has been reworked to use multiple storage layers:

request memory → Redis / Memcached when available → persistent disk storage

The goal is to avoid unnecessary repeated work during a request while still having a persistent fallback when an external cache backend is not available.

Static page cache, WP_Query cache and database query cache remain separate and keep their own lifetime, invalidation and exclusion rules.

AVIF support

The Media Optimizer can now convert images to AVIF in addition to WebP.

If both are enabled, AVIF takes priority where supported. Conversion is handled locally on the server, and failed conversions should leave the original image and attachment metadata untouched.

Navigation prefetching

I also changed how early navigation prefetching works.

On WordPress 6.8+, WP Optimizer can integrate with WordPress Core speculation rules instead of always relying on its own JavaScript implementation.

Older WordPress versions still use hover/touch prefetching.

There is also an option to disable WordPress native speculative loading when it causes unwanted requests.

Module architecture

One of the bigger changes is internal.

Modules are now registered through an explicit module catalog instead of relying on module discovery and duplicated metadata inside every module.

The goal is simpler initialization, more predictable lazy loading and less unnecessary work on normal WordPress requests.

This is part of a broader effort to keep the plugin modular not only in the UI, but also internally.

LiteSpeed / OpenLiteSpeed compatibility

I fixed generated .htaccess directory protection rules that could be rejected by LiteSpeed.

Existing installations also refresh the WP Optimizer-managed security rule block during the upgrade, so old invalid rules should not remain behind after updating.

The plugin now distinguishes more clearly between Apache, LiteSpeed Enterprise, OpenLiteSpeed and Nginx behavior instead of assuming all Apache-compatible servers behave identically.

There have also been smaller improvements around the admin UI, debugging infrastructure, cache backends and internal storage.

WP Optimizer currently includes:

• Static page cache
• Object cache with Redis / Memcached
• WP_Query and database query caching
• HTML / CSS / JavaScript minification
• Browser caching and GZIP / Brotli
• Image optimization, WebP and AVIF
• Lazy loading and LCP optimization
• Navigation prefetching
• Page Test performance comparisons
• Performance Monitor
• Database cleanup and backups
• Cron Manager
• Media Cleaner
• Cloudflare integration
• Activity logging
• WordPress / server diagnostics
• Security hardening
• Update controls
• Mail logging / SMTP
• WordPress feature / admin cleanup
• Configuration backups, restore and module resets

The direction I’m trying to take is increasingly less “another cache plugin” and more a self-hosted WordPress performance toolkit where you can measure a problem, enable the relevant optimization and then verify whether it actually improved anything.

I’d be particularly interested in feedback from people managing production WordPress sites:

Would you actually use AVIF conversion directly inside an optimization plugin, or do you prefer handling images elsewhere?

Do you use WordPress speculative loading / navigation prefetching, or have you found it causes more problems than it solves?

For caching, do you prefer plugins to automatically choose the best available backend, or expose the individual cache layers?

How important is LiteSpeed / OpenLiteSpeed support when choosing a performance plugin?

And more generally: what would WP Optimizer need before you would trust trying it on a production site?

What am I still missing? Which part would you test first?