robeyupdraft

Thanks Jeff, really appreciate you taking the time to leave a review. The feature-rich free version is something we feel strongly about keeping that way. A huge chunk of WordPress runs on sites that can’t justify another monthly subscription, and we’d rather those sites have access to proper performance tools than lock all the good stuff behind a paywall.

Thanks again from the team.

Thank you for taking the time to write such a thoughtful review, this is exactly the kind of feedback that makes our day.

You’ve actually put your finger on one of the things we care about most: the all-in-one angle. A lot of WordPress sites end up stacking a caching plugin, an image optimizer, a database cleanup tool, and a minifier all on top of each other, and the irony is that the plugin bloat starts eating into the performance gains you were chasing in the first place. Keeping everything under one roof (and one settings page) is a deliberate design choice, so it’s really rewarding to hear it landing the way we hoped.

We’re also glad the balance between beginner-friendly and powerful-enough-for-advanced-users is working for you. That’s a surprisingly hard line to walk, and it’s something we’re always tweaking.

If you ever bump into something that could be smoother, the support forum is the fastest way to get it in front of us. Thanks again from the whole team.

Muito obrigado pela avaliação! Ficamos felizes em saber que o WP-Optimize está atendendo às suas expectativas. O seu apoio significa muito para a nossa equipe.

Hi @yb1313, thanks for taking the time to leave feedback. I’m Robey, Product Manager for WP-Optimize, and I’d like to help you get to the bottom of this rather than leave it as an unresolved conflict.

You wrote: “it caused a rotating graphics element that I had on my website, to malfunction and mess up its clickable links. After disabling the WP-optimize plugin, the issue was resolved.”

That description points very strongly to a specific, fixable cause: our Minify feature was almost certainly merging or minifying the JavaScript that powers your slider or carousel, and the merged bundle broke the script’s initialization. Sliders are one of the most common categories of plugin that need their JS excluded from processing, because they often rely on specific load order and inline configuration that don’t survive being combined with other scripts.

The good news is you don’t have to choose between optimization and a working slider. There are two straightforward options:

1. Go to WP-Optimize → Minify → JavaScript
2. Scroll to Exclude JavaScript from processing
3. Add a wildcard pattern matching the slider plugin’s folder, for example */plugins/your-slider-plugin-name/*
4. Save, then purge the cache from WP-Optimize → Cache

Minification conflicts are a real category of problem, and we take them seriously. A few things worth knowing:

• We maintain a growing list of default exclusions for known-problematic scripts, and we add to it with every release.
• Every cache and minification plugin on the market, including the paid ones, requires some level of per-site tuning when aggressive JavaScript optimization is involved. It isn’t a flaw unique to WP-Optimize, but that doesn’t mean we can’t do better at guiding people through it, and we’re actively working on exactly that.

If you’re willing to give it another try, please open a thread in the support forum with the name of the slider and a link to the page where it was breaking. We’ll make sure you get a working configuration, and if we can reproduce it, we’ll add the fix to our defaults so it stops being a problem for everyone.

Either way, I appreciate the feedback. The only reviews we learn nothing from are the ones nobody writes.

Robey
Product Manager, WP-Optimize

Hi @and4zej, Robey here. I’m the product manager for WP-Optimize. Thanks for taking the time to write this up. A couple of your points describe behaviour we’d treat as critical if reproduced, and the rest I think we can clear up. Let me take them one at a time.

WP-Optimize fails to fully de-register its components even when caching is toggled off in the UI. Its hooks and filters remain active on every page load […] Crucially, the “disable” toggle only stops the generation of new cache files; it doesn’t cease the plugin’s interference with WooCommerce internals.

You’re partly right, and it’s worth being precise about what’s happening. When page caching is disabled via the toggle, WP-Optimize stops serving and writing cached pages, but some hooks do remain registered. Specifically, the ones that manage:

• Purge triggers (so the plugin knows when to clear cache on content changes)
• Exclusion rules and conditional tags
• The admin UI and settings screens

That’s by design, and it’s the same pattern every major cache plugin uses, because those hooks need to be present for the plugin to respond to settings changes and purge events. What those remaining hooks should not be doing is modifying the wc-ajax=get_refreshed_fragments response. If you’re seeing evidence that they are, that’s a bug I want to see fixed, not defended.

This results in critical UI failures, such as customers seeing incorrect cart contents or random items.

This is the claim I’m taking most seriously. A cache serving one customer’s cart to another is a critical issue, and it’s not something we’ve been able to reproduce in-house or seen reported through our support channels. To investigate properly I need more than I can get from a review thread.

If you’re willing, please open a support topic at ww.wp.xz.cn/support/plugin/wp-optimize and include:

• Your WP-Optimize version
• Your WooCommerce version
• Any other caching or optimization plugins active, including at the server or CDN level
• Your active theme
• The steps that produced the incorrect cart contents, ideally with a timeline

If there’s a genuine session-bleed bug here I want my team to take a look ASAP.

The “broken site” symptoms post-update are a direct result of 24-hour stale cache being served, where outdated CSS/JS assets no longer align with the updated plugin output.

Here I’d push back gently. The 24-hour figure is the default cache lifespan, which is configurable under Cache > Page cache > Cache options. More importantly, WP-Optimize purges its own page cache and minify cache automatically when the plugin updates, so visitors shouldn’t be served stale assets from us after an update completes.

If you’re seeing stale CSS or JS after an update, the usual culprits are one of the following:

• A separate minify cache from another plugin
• A CDN that wasn’t purged as part of the update
• Browser cache on the tester’s own machine

Happy to help diagnose which, if you can share a specific example.

The public support forum is the right place to take this forward, and it’s where our team actively triages reports from our users. Open a topic with the details above and we’ll pick it up from there. I’d genuinely like to get to the bottom of what you saw.

Robey
Product Manager, WP-Optimize

Hi Jan, Robey here, Product Manager for WP-Optimize. Thanks for the detailed feedback. I’d rather respond to each point properly than brush it off with a generic reply, so working through them in order:

breaks websites with the newest Divi Theme (Divi 5)

If WP-Optimize is breaking Divi 5 sites, that’s a regression we need to reproduce and fix. I’d like to get this in front of our dev team directly. If you’re willing, please open a ticket at teamupdraft.com/support with your Divi 5 version and what specifically breaks, and I’ll flag it personally so it doesn’t sit in the queue.

missing options to cache query strings (very important if you use WooCommerce filter for example)

I want to make sure we’re talking about the same thing here, because WP-Optimize Premium does have a query variables setting by going to Cache → Advanced settings → Ignore these query variables when caching. You can list query string keys there that shouldn’t break cache lookup.

impossible to completely disable/hide the image compression

You’re right. There isn’t a clean way to remove the entire image compression module from the plugin today. The existing toggles do this much:

• Auto-compress new images on upload: switches off automatic processing
• Show WP-Optimize meta box on media page: hides the per-image controls in the Media Library

The Images tab itself stays visible either way. It’s fair criticism, and it connects to a wider conversation we’re having about letting people turn off parts of the plugin they don’t use. Noted.

my email address is shown in plugin list

This one I want to understand better before saying anything definitive. Are you referring to the licensed user email being displayed on WP Dashboard → Plugins?

If WP Rocket and WP Fastest Cache are working for you, I’m not going to argue. But the issues you’ve raised are ones we should either fix or explain properly, and I’d rather hear them than not. Thanks for taking the time to write this up.

Robey
Product Manager, WP-Optimize