Before you reach for PHP Memory Limit, stop — that's usually the wrong knob to turn. Something else is almost always eating the RAM first. WooCommerce is a fundamentally different animal from a regular WordPress site in terms of resource load: products, cart, checkout, order management in the admin, Cron jobs, plugins, database queries — all of it is piling weight onto PHP and MySQL simultaneously. The symptoms are recognizable: Allowed memory size exhausted errors, the orders screen in wp-admin dragging, checkout pages loading slowly, PHP processes hogging RAM, the server throwing high-memory alerts repeatedly, and occasionally a 502 or 503 thrown in for good measure.
Here's the concept worth nailing down before anything else, because it's the thing most people get backwards: raising the PHP Memory Limit doesn't mean the server actually has more RAM available. That single distinction is really the crux of this whole topic.
How much memory should you actually allocate? There isn't one right answer
There's no universal number that fits every store, but this table works as a reasonable starting point for deployment:
| WooCommerce scale | Suggested server RAM | PHP Memory Limit |
|---|---|---|
| Test site / small shop | 2GB | 256MB |
| Small production site | 2–4GB | 256–512MB |
| Mid-sized store | 4–8GB | ~512MB |
| Large store | 8GB+ | Adjust based on actual load |
Some benchmarks recommend starting WooCommerce sites at 512MB outright, with at least 2GB reserved even for smaller sites. Neither approach is wrong, really — one is "start conservative, add more when problems show up," the other is "give yourself enough headroom upfront so you're not constantly fiddling with it." Which one fits you depends on how much time you're willing to spend watching logs. What's genuinely not advisable is jumping straight to 1GB out of the gate. If your server is running multiple PHP Workers simultaneously and each one can max out at that ceiling, you can end up putting more pressure on the server, not less.
PHP Memory Limit and server RAM are not the same thing
PHP Memory Limit caps how much memory a single PHP request can use. Server RAM is the physical memory available to the entire machine. Having 4GB of server RAM doesn't mean every individual PHP process gets to use the full 4GB on its own. Say you're running 6 PHP Workers, each peaking at 150MB — that's already 900MB just from PHP, before MySQL, Redis, Nginx, the OS itself, and Cron jobs take their share. A 4GB server fills up fast under that load, and raising the PHP Memory Limit does nothing to fix it.
If you're on Cloudways, the path to adjust this is: go into your Application settings, find the PHP configuration section, and bump Memory Limit from 256M to 512M (exact labeling shifts slightly between interface versions, but look for "PHP Settings"). Beyond just memory_limit, sites with lots of product variations or complicated checkout fields typically need max_execution_time, max_input_time, and max_input_vars adjusted alongside it. Touching only the memory ceiling while ignoring these often means the same underlying problem resurfaces — just wearing a different error message.
Figure out who's actually eating the memory before you touch anything
Seeing RAM sitting at 80% is not, on its own, a reason to go change PHP settings. First check whether it's a swarm of PHP Workers consuming it, whether MySQL is running hot on memory or CPU, whether Redis is configured sensibly, whether Cron is generating a pile of background jobs, whether you've got too many resource-heavy components installed (WooCommerce extensions, Elementor, security plugins, backup plugins), and whether bots or scrapers are hammering the site continuously.
PHP-FPM Worker count is the variable people overlook most often. A lot of people fixate purely on how much RAM the server has and don't realize Worker count is its own separate lever entirely — a 4GB server running too many PHP Workers can actually run out of memory faster than the same 4GB server running a sensible number of Workers, simply because each Worker claims its own chunk of memory. Too few Workers shows up as pages queuing, checkout stalling, admin requests hanging, and TTFB climbing — sometimes CPU usage isn't even high, the site's just slow. Too many Workers can blow through RAM fast during traffic spikes, triggering swap, OOM kills, and 502/503 errors, with MySQL taking collateral damage too. This number needs to be tuned against your actual server RAM and traffic patterns — copying a "recommended" figure from some forum post isn't going to hold up.
Redis Object Cache is usually a better investment than just adding memory
For WooCommerce specifically, turning on Redis Object Cache tends to move the needle more than raising PHP Memory Limit ever will. It caches database objects and query results, cutting down how often WordPress has to hit MySQL — which matters a lot on sites with heavy dynamic content like product catalogs, user accounts, and category pages. Cloudways servers ship with Redis available by default; you enable it through the Object Cache Pro plugin.
But Redis doesn't fix every caching problem. WooCommerce is loaded with dynamic content — cart, checkout, and account pages can't be treated like a blog homepage and just fully cached as static pages. Object Cache and Page Cache are two completely different mechanisms — one manages database queries, the other manages whether a page gets regenerated on every load — and conflating them is where caching setups go wrong. The classic mistake is accidentally including /cart/, /checkout/, or /my-account/ in page caching rules. Once those pages get cached, customer A's cart contents can leak into customer B's session, or checkout state can behave erratically. These paths need to be explicitly excluded from page caching, no exceptions.
Plugin count, Elementor, and background Cron
Plugins are the easiest thing to check and, somehow, still the most commonly ignored — particularly SEO, security, backup, analytics, email, page builders, and WooCommerce extensions. If five different plugins are all hooking into WooCommerce's order events simultaneously, PHP execution time and database queries both climb together, and memory and CPU end up squeezed at the same time. Elementor paired with WooCommerce is a classic memory-hungry combo — pile on a bunch of Elementor addons and the admin gets progressively heavier. Don't install a bloated plugin just to get one small feature.
A huge chunk of what WooCommerce does relies on WP-Cron — order-related tasks, scheduled actions, emails, webhooks, product syncing, all of it fires through Cron. Here's an adjustment that gets overlooked constantly: WordPress's default WP-Cron is actually a "fake" cron — it only checks for pending tasks when a visitor loads the site. On stores with real traffic or a meaningful order volume, it's worth disabling that default and switching to a genuine server-level system Cron job instead, which noticeably cuts the overhead added to every page load. Once order volume grows, check the Scheduled Actions section under WooCommerce's Status page, and pay attention specifically to Pending and Failed counts. A big backlog there means the background job queue can't keep up — and the fix is addressing Cron and Action Scheduler directly, not throwing more server RAM at it.
The database and Autoload data deserve a look too
WooCommerce's database keeps growing as orders, customers, products, sessions, and logs pile up. Tables like wp_actionscheduler_actions accumulating over time can genuinely drag down database performance, so it's worth periodically checking table sizes, slow queries, and leftover transient data. Another spot that's easy to miss is WordPress's Autoload behavior — plenty of plugins write large amounts of data into the wp_options table flagged for autoloading. If that dataset gets bloated, every single request ends up loading a pile of irrelevant configuration data along with it, pushing RAM usage and TTFB up in the process. Cleaning out leftover autoload data from plugins you no longer use can sometimes have a more immediate effect than simply bumping memory limits.
PHP version and testing in staging before you go live
Stick to a reasonably current, stable PHP version that Cloudways, WordPress, WooCommerce, and your installed plugins all actually support — don't stay stuck on an outdated version indefinitely just to accommodate one legacy plugin. Before changing PHP version, memory limits, Worker count, Redis, caching, or database settings, make those changes in a staging environment first and confirm everything works before pushing to production. Don't go changing a pile of settings all at once directly on a live store that's actively processing orders.
When it's time to upgrade the server instead of tweaking more settings
If you've already cleaned up plugins, set up Redis, optimized caching, tuned PHP, cleaned the database, and fixed Cron — and RAM usage is still sitting above 90% consistently, or swap usage keeps climbing — that's the point to upgrade server RAM rather than keep raising the PHP Memory Limit. Here's a practical gut check: if Memory Limit is already at 512M but overall server RAM is chronically near 100%, bumping it to 768M or 1GB usually accomplishes nothing — the bottleneck isn't that setting. Growing order volume, a rising product count, more concurrent users, PHP Workers maxing out regularly, MySQL chewing up resources persistently, swap getting used frequently, or 502/503 errors showing up during traffic peaks — when you're seeing these, upgrading the server is generally more reliable than continuing to micro-tune parameters.
One of the most common mistakes: testing only how fast the homepage loads, and never testing the actual checkout flow. A fast-loading homepage tells you nothing about whether checkout is healthy — WooCommerce's real performance problems tend to hide specifically in the cart and checkout pages, and skipping that step when diagnosing memory issues means missing exactly where the trouble usually lives.