When WordPress Runs Out of Room
Every WordPress page request allocates PHP memory — space for WordPress core, active plugins, the theme, and the content being assembled. WordPress sets a default memory limit of 40MB for frontend requests and 256MB for admin requests. When plugins and themes push memory consumption toward or past these limits, the consequences range from degraded performance to fatal errors that crash the page entirely.
High memory usage is a stability problem as much as a performance one. A site that routinely uses 80% of its memory limit works fine under normal traffic but fails under load, when multiple concurrent requests each need their full allocation and the server runs out of available memory.
What Consumes PHP Memory
Plugin initialization: Every active plugin is loaded into memory on every request, even if its functionality is not used on the current page. A plugin with large PHP class libraries, bundled dependencies, or extensive configuration arrays consumes memory just by being active. This is distinct from execution time — a plugin can be fast but memory-hungry if it loads large data structures at startup.
Database result sets: When a plugin queries the database and loads results into PHP arrays, that data occupies memory. A plugin that fetches thousands of rows — all users, all products, all posts — to filter them in PHP rather than in the SQL query can consume tens of megabytes from a single query. This is especially common in reporting plugins, export tools, and poorly-optimized search implementations.
Content processing: Page builders that parse complex content structures, plugins that process large text blocks (shortcode expansion, content filtering), and image manipulation libraries all consume memory proportional to the size of content they process.
Object accumulation: PHP’s garbage collector handles memory cleanup, but during a single request, all allocated objects remain in memory until the request completes. Plugins that create many temporary objects — iterating over large datasets, building complex data structures — can peak at high memory usage even if each individual allocation is small.
Symptoms of High Memory Usage
The most obvious symptom is the PHP fatal error: “Allowed memory size of X bytes exhausted.” This kills the page request and typically shows a white screen or a brief error message. But memory problems often manifest subtly before they reach the fatal threshold:
- Intermittent failures — pages that usually work but occasionally fail, because memory usage varies with content length, query results, or concurrent requests
- Admin slowness — the WordPress dashboard is often more memory-intensive than the frontend because it loads additional admin-specific plugin code
- Failed updates — plugin and WordPress core updates sometimes fail mid-process when the update mechanism exceeds memory limits
- Import/export failures — bulk operations that process many records in a single request hit memory limits before completion
Why Increasing the Limit Is Not a Fix
The common advice is to increase WP_MEMORY_LIMIT in wp-config.php. This is a valid short-term workaround, but it does not solve the underlying problem — it just moves the threshold. A site consuming 200MB of memory per request has a plugin or theme that is architecturally wasteful. Raising the limit to 512MB means each concurrent request uses 200MB, so a server with 2GB of RAM can only handle 10 concurrent requests before running out of memory entirely.
The sustainable approach is identifying which plugins consume the most memory and evaluating whether they can be replaced, configured differently, or supplemented with caching that reduces their per-request memory footprint.
How to Measure Memory Usage
Query Monitor displays peak memory usage for each page load in its overview panel. WordPress itself tracks memory via memory_get_peak_usage(), and some hosting dashboards surface this metric. For per-plugin memory attribution, profiling tools that track memory allocation per function call provide the most granular data.
A healthy WordPress site should use well under 64MB on frontend requests. Sites consistently exceeding 128MB on frontend pages have a plugin or theme that warrants investigation.
Tools That Can Help
Query Monitor shows peak memory usage in its overview panel for every page load. It is the quickest way to check whether your site has a memory problem and to correlate memory spikes with specific pages or actions.
Further Reading
- Performance Optimization (WordPress Developer Resources) — WordPress’s official performance documentation, including memory management considerations.