Most WooCommerce stores try to speed things up by installing yet another cache plugin. It works up to a point, but the real ceiling is set by the server: PHP, the database, the object cache, and above all that WP-Cron that fires on every visit. When that is properly sorted at the system level, the store flies. When it is not, no plugin saves you during a campaign.
I handle the system layer: the server, the operating system, and all the services WordPress and WooCommerce run on. The store itself — theme, plugins, code, and WordPress/WooCommerce updates — is handled by the agency or your development team. My job is to make sure the environment where the store lives is fast, secure, monitored, and available.
I work mainly with agencies and developers who need a systems specialist for their WooCommerce projects without adding one to the payroll, and also directly with e-commerce managers who want a store that holds up. In the background, as an extension of your team.
Where I start: the problems I usually find
Most WooCommerce projects arrive with one of these symptoms:
- The store is slow and the cache plugin is not enough. High TTFB, heavy cart and checkout, wp-admin that drags. The plugin caches the homepage, but the pages that really matter in a shop cannot be cached the same way — and that is where the server shows itself.
- WP-Cron out of control. WordPress scheduled tasks fire on every visit, loading the server exactly when traffic is highest. It is one of the most common bottlenecks and is solved at the system level.
- It goes down exactly when it sells the most. Sales, Black Friday, a newsletter that works too well… and the server gives up at the worst possible moment.
- Attacks on wp-login and xmlrpc. WordPress is the most attacked CMS in the world: brute force on the login, XML-RPC abuse, relentless bots. Much of that can be cut off before it even reaches PHP.
- A migration or a new server. Moving off shared hosting that has become too small, changing server, or consolidating — without losing sales or SEO. (Store updates are coordinated by your team; I prepare and migrate the infrastructure.)
If any of those sound familiar, that is where I come in.
How I solve it
I do not sell magic recipes, generic “optimisations”, or yet another plugin. The approach is always the same: measure, dimension, and tune the specific stack of your store at the server level.
I start from real data (server metrics, service profiling, traffic logs from past campaigns) to find where the actual bottleneck is before touching anything. From there I tune each service in the stack — web server, PHP, database, object cache — for the real load pattern of your store, leave everything documented and reproducible, and stay available for peaks. The idea is to have the infrastructure ready before the campaign, not fighting fires during it. The store runs on top; I make sure it has solid ground beneath its feet.
What is included
This is what I contribute at the system level in a WooCommerce project. You do not need to take all of it: it adapts to what the project needs.
Performance and stack tuning
- Tuning of PHP-FPM and OPcache for the store’s real load pattern (pools, workers, memory).
- Configuration of the web server (Nginx or Apache) with FastCGI cache, compression, static cache, and HTTP/2 or HTTP/3.
- Server-level page cache correctly excluding cart, checkout, and customer account — exactly what a cache plugin usually gets wrong in a shop.
- Provisioning and tuning of Redis / Memcached as a persistent WordPress object cache.
- WP-Cron disabled and replaced by a real system cron, so scheduled tasks stop firing on every visit.
- Tuning of MariaDB/MySQL (buffer pool, connections, slow queries) — very sensitive to the weight of
wp_options, transients, and plugins. - Provisioning of the search service (e.g. Elasticsearch for ElasticPress) if the project requires it.
Campaign and peak preparation
- Pre-event load tests to know the server’s real ceiling before the event.
- Resource sizing (vertical and, where applicable, horizontal with load balancing) to handle the peak.
- Contingency plan and reinforced availability (on-call) during the critical window.
Security and hardening
- Server hardening and protection of wp-login.php and XML-RPC (rate limits, fail2ban, brute-force blocking) before the request even reaches PHP.
- System security updates: OS, kernel, and stack services kept up to date. (WordPress, plugin, and theme updates are your team’s responsibility; I keep what is underneath secure.)
- WAF in front of the store (Cloudflare, ModSecurity, or others) and bot and scraping mitigation.
- Firewall, correct file permissions, and security headers at the web server level.
- Best practices aligned with PCI-DSS compliance on the infrastructure side, and TLS certificate management with automatic renewal.
Infrastructure migrations
- Hosting or server migrations with no perceptible downtime and no SEO loss.
- Moving off shared hosting to a properly sized dedicated or cloud environment.
- Provisioning of equivalent staging and production environments, so your team deploys and tests on a solid base.
- Data and service migration at the system level, with a clear rollback plan if something goes wrong.
Backups and monitoring
- Encrypted, offsite, tested backups (3-2-1 rule): a backup that has never been restored does not count.
- Continuous monitoring of server, services, and availability — so you find out before your client does.