In a recent Business Bloomer Club Slack thread, a member raised concerns about persistent CPU spikes on a VPS running a WooCommerce site.
Despite solid specs (16 cores, 32GB RAM), aggressive caching (WP Rocket, Redis, Varnish), and Cloudflare firewall rules in place, the site was still experiencing major slowdowns and outages. The suspicion fell on a mix of slow database queries from WPML and ongoing bot attacks.
This sparked a familiar discussion among Club members: how do you actually determine the root cause of performance issues, especially when WooCommerce is paired with heavy plugins like WPML? And more importantly, what’s the right sequence of actions when a production site is under pressure?
WPML and Performance: A Known Tradeoff
One quick response pointed out a reality many WooCommerce devs already know: WPML tends to introduce performance problems, especially on stores with large product catalogs or complex content structures.
This isn’t new. Database queries generated by WPML can be significantly more expensive, and caching often isn’t enough to completely mask the overhead.
While disabling WPML might not be an option for stores that rely on multilingual features, this case reinforces the need to constantly monitor slow queries and audit plugins that interact heavily with the database.
Don’t Guess — Look at Logs First
Another Club member emphasized that speculation, firewall tweaks, and plugin blame games won’t get you far unless the root cause is known. Instead of stacking on more solutions or tweaking Cloudflare rules blindly, the advice was clear: pause and analyze.
That means reviewing:
- Server logs, particularly during the spike times
- Slow query logs in MySQL/MariaDB
- Analytics data for user/bot patterns
- Cloudflare traffic reports for anomalies
Only after understanding what triggered the spike — whether it’s a botnet hammering wp-login.php, a sudden spike in XML-RPC requests, or a broken plugin query — should one take further action.
Security Measures: What Else Can Help?
Besides performance, bot activity was a real concern in this case. The site owner had already blocked empty user agents and wp-admin traffic via Cloudflare, but attacks were still getting through.
Other measures that can help include:
- Rate limiting or JavaScript challenge for sensitive paths
- Using a WAF with bot management (Cloudflare Pro or Enterprise tiers)
- Implementing fail2ban with NGINX/Apache to block IPs repeatedly hitting login endpoints
- Monitoring for common patterns like
/?rest_route=/,xmlrpc.php, or fake search engine crawlers
Some WooCommerce site owners also offload search and translation features to external services — such as Elasticsearch and third-party multilingual APIs — to minimize local load.
Plugin Alternatives: Do They Help?
For multilingual needs, alternatives like TranslatePress, Weglot, or MultilingualPress are often mentioned. However, none are entirely free of performance costs. Weglot and MultilingualPress reduce database overhead because of their different architecture (Weglot handles it off-site, MultilingualPress uses multisite), but may come with tradeoffs in flexibility or cost.
Ultimately, if multilingual functionality is not critical for SEO or user experience, a simpler setup (e.g. separate subdomains per language with manual translations) might offer better stability.
Conclusion
Server CPU spikes on WooCommerce setups are complex problems — especially when involving plugins like WPML and unknown bot activity.
While tools like Redis, Varnish, and Cloudflare can help stabilize load, none replace proper diagnostics.
As the Slack thread concluded, unless the cause of a spike is known, further tweaks are mostly guesswork.
Start with logs, stay analytical, and treat performance issues like bugs: identify, reproduce, resolve.
