wp-config.php Constants for WooCommerce Performance

WooCommerce performance is usually discussed in terms of hosting, caching plugins, database cleanup, image optimization, and CDN setup. Those things matter, but there is another layer many store owners ignore: the wp-config.php file.

The wp-config.php file controls important WordPress constants before the site fully loads. For WooCommerce stores, the right constants can help with PHP memory, admin stability, caching behavior, cron load, debugging overhead, database growth, and safer production settings.

These constants will not magically turn weak hosting into a fast store. They also will not fix bad plugins, slow database queries, oversized images, or a broken checkout. But used correctly, they can reduce avoidable overhead and make WooCommerce more stable under real store activity.

This guide explains the most useful wp-config.php constants for WooCommerce performance, what each one does, safe values to use, and which constants you should avoid changing blindly.

For a safer starting point, use the FyrePress wp-config.php Builder to generate a clean configuration block instead of copying random snippets into a live store.

What Is wp-config.php?

wp-config.php is the main WordPress configuration file. It usually sits in the root folder of your WordPress installation, near wp-admin, wp-content, and wp-includes.

This file contains database credentials, security salts, table prefix, and constants that control how WordPress behaves. Because it loads early, it is the correct place for many performance-related settings that need to exist before WordPress, WooCommerce, plugins, and themes fully initialize.

For WooCommerce, this file matters because stores place heavier demands on WordPress than a normal blog. A store has carts, sessions, checkout, payment gateways, product queries, customer accounts, background jobs, order processing, emails, and admin reports.

Before Editing wp-config.php

Editing wp-config.php is powerful but risky. A missing semicolon or bad quote can break the entire site.

Before adding performance constants:

• Download a copy of the current wp-config.php file.
• Take a full site backup.
• Use a plain code editor, not Microsoft Word or Google Docs.
• Add constants above the “That’s all, stop editing” comment.
• Make one change at a time.
• Test product pages, cart, checkout, payment, and admin order screens after changes.

For the safest editing workflow, read How to Safely Edit wp-config.php Without Breaking WordPress.

Quick Performance Constants Table

1. WP_MEMORY_LIMIT

WP_MEMORY_LIMIT controls the amount of memory WordPress can request for normal site operations. For WooCommerce, this matters because store pages can be heavier than standard posts or pages.

A practical WooCommerce baseline is:

define( 'WP_MEMORY_LIMIT', '256M' );

This can help reduce memory-related failures on product pages, cart actions, plugin processes, and normal store operations.

However, memory is not a speed booster. If a request only needs 90 MB, setting the limit to 512 MB will not automatically make the request faster. It simply allows heavier requests to complete instead of crashing.

Use this when:

• WooCommerce reports low memory in system status.
• You see “Allowed memory size exhausted” errors.
• Product imports fail.
• Checkout or admin tasks crash under normal use.
• You use page builders, subscriptions, memberships, or many extensions.

Do not set memory to a huge value without checking total server RAM and PHP worker limits. Use the FyrePress PHP Memory Limit Calculator to estimate a safer value.

2. WP_MAX_MEMORY_LIMIT

WP_MAX_MEMORY_LIMIT controls the higher memory limit WordPress can use for admin and backend operations. This is especially important for WooCommerce because many heavy store tasks happen inside the dashboard.

A practical value for many WooCommerce stores is:

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

This can help with:

• WooCommerce admin reports.
• Order management screens.
• Product imports and exports.
• Bulk product edits.
• Image regeneration.
• Plugin and theme updates.
• Database migrations.
• HPOS migration tasks.

For larger stores, 768M may be reasonable during imports or database-heavy tasks, but do not use large values blindly on small servers.

3. WP_CACHE

WP_CACHE tells WordPress to load the advanced cache drop-in file if it exists. It does not create a caching system by itself. It only enables compatible caching behavior when a cache plugin, host cache, or drop-in file is properly installed.

Typical value:

define( 'WP_CACHE', true );

This can help WooCommerce performance when your caching system is configured correctly.

Important WooCommerce warning: do not cache cart, checkout, account, order received, or customer-specific pages like static pages. WooCommerce pages that show cart or customer data must stay dynamic.

Safe pages to cache often include:

• Homepage.
• Blog posts.
• Static pages.
• Product category pages.
• Many product pages, depending on stock, pricing, and personalization rules.

Pages to exclude from cache include:

• Cart.
• Checkout.
• My Account.
• Order received pages.
• Customer dashboards.
• Any page with personalized pricing or customer-specific content.

Use WP_CACHE only as part of a complete WooCommerce-safe caching setup.

4. DISABLE_WP_CRON

By default, WordPress checks scheduled tasks on page load. For a WooCommerce store, this can create random performance pressure because scheduled actions, plugin tasks, emails, cleanup jobs, and background processes may fire during visitor requests.

On serious stores, it is often better to run cron through the server scheduler instead of relying on visitor traffic.

After setting up a real server cron job, add:

define( 'DISABLE_WP_CRON', true );

This can help reduce frontend request spikes caused by cron checks.

Important: do not add this before setting up server cron. If you disable WP-Cron without a replacement, scheduled posts, WooCommerce actions, subscription renewals, emails, cleanup jobs, and plugin tasks may stop running correctly.

A typical server cron command calls:

https://example.com/wp-cron.php?doing_wp_cron

Or through CLI, depending on your hosting setup.

5. WP_CRON_LOCK_TIMEOUT

WP_CRON_LOCK_TIMEOUT controls how long WordPress prevents overlapping cron processes. This can matter on busy WooCommerce stores where slow scheduled jobs or repeated page-load triggers create cron pressure.

Example:

define( 'WP_CRON_LOCK_TIMEOUT', 60 );

For most stores, the default behavior is fine. Consider this only when you are actively troubleshooting overlapping cron jobs, stuck scheduled actions, or repeated background processes.

Before changing it, check:

• WooCommerce scheduled actions.
• Failed actions.
• Server cron frequency.
• PHP execution time.
• Background job logs.

This is not a first-step optimization. It is a tuning option for stores that already understand their cron behavior.

6. WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY

Debugging is useful during troubleshooting, but it should not be left active carelessly on a live WooCommerce store.

For production, a safe default is:

define( 'WP_DEBUG', false );

When actively troubleshooting, use private logging instead of public display:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

After troubleshooting, turn debug mode off again.

Why this matters for WooCommerce:

• Public errors can scare customers during checkout.
• Error output can break AJAX responses.
• Debug logs can grow large if ignored.
• Logs can expose file paths, plugin names, and sensitive technical details.
• Repeated warnings can hide the real fatal error.

If your store shows fatal errors, use the FyrePress WordPress Error Log Decoder to understand the issue before guessing.

7. SAVEQUERIES

SAVEQUERIES stores database queries for debugging. It can help developers find slow queries, repeated queries, and heavy plugin behavior.

For troubleshooting only:

define( 'SAVEQUERIES', true );

For production performance:

define( 'SAVEQUERIES', false );

Leaving SAVEQUERIES enabled on a live WooCommerce store can hurt performance because WordPress stores query information during requests. This is especially risky on stores with many product queries, filters, cart actions, logged-in customers, and admin reports.

Use it briefly, collect the information, then disable it.

8. WP_POST_REVISIONS

WooCommerce stores can accumulate many revisions from product edits, page builder edits, landing pages, and product description changes. Over time, unlimited revisions add database weight.

A practical setting is:

define( 'WP_POST_REVISIONS', 5 );

This keeps a reasonable revision history without storing every edit forever.

You can use a lower or higher value depending on the store workflow:

• 3 for lean stores with simple editing.
• 5 for most WooCommerce stores.
• 10 for editorial-heavy stores.

Avoid disabling revisions completely unless you are certain your team does not need rollback history for product descriptions, landing pages, policies, and content edits.

9. AUTOSAVE_INTERVAL

AUTOSAVE_INTERVAL controls how often WordPress autosaves while editing content. The default is usually frequent enough to protect editors, but on large admin workflows, constant autosaves can add background requests.

Example:

define( 'AUTOSAVE_INTERVAL', 180 );

This increases autosave spacing to three minutes.

Use this carefully. Longer autosave intervals may reduce admin noise, but they also increase the risk of losing recent edits if the browser crashes or the editor closes unexpectedly.

This is most useful for stores where admins edit heavy product pages, long descriptions, or page-builder content and autosaves are contributing to admin lag.

10. EMPTY_TRASH_DAYS

EMPTY_TRASH_DAYS controls how long WordPress keeps trashed posts, pages, attachments, and comments before deleting them permanently.

A practical value is:

define( 'EMPTY_TRASH_DAYS', 7 );

This reduces long-term clutter while still giving the team a recovery window.

Do not set this to 0 casually:

define( 'EMPTY_TRASH_DAYS', 0 );

That disables trash behavior and permanently deletes items immediately. For WooCommerce stores with teams, products, media, and policies, immediate deletion can be risky.

A safer range is usually 7 to 15 days for active stores.

Recommended WooCommerce wp-config.php Performance Block

Here is a practical baseline for many WooCommerce stores. Add it above the “That’s all, stop editing” line in wp-config.php.

/* WooCommerce performance-safe baseline */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

define( 'WP_CACHE', true );

/* Use only after real server cron is configured */
define( 'DISABLE_WP_CRON', true );
define( 'WP_CRON_LOCK_TIMEOUT', 60 );

/* Production-safe debugging */
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SAVEQUERIES', false );

/* Database hygiene */
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 180 );
define( 'EMPTY_TRASH_DAYS', 7 );

Do not paste this blindly. Adjust it to your server, store size, cron setup, caching system, and editing workflow. The FyrePress wp-config.php Builder can help generate a cleaner version for your specific setup.

Which Constants Should Store Owners Avoid?

Some constants look useful but are not general WooCommerce performance fixes.

Performance constants should reduce risk, not create new failure points.

wp-config Constants vs Real WooCommerce Performance Work

wp-config constants are only one layer. A store can have perfect constants and still be slow if the main performance stack is weak.

You still need:

• Quality WooCommerce hosting.
• Modern PHP version.
• OPcache.
• Object cache for larger stores.
• WooCommerce-safe page cache.
• CDN for static assets.
• Optimized product images.
• Clean plugin stack.
• HPOS where compatible.
• Database cleanup.
• Checkout testing after every optimization.

For the full store workflow, read WooCommerce Performance Checklist: Hosting, Caching, and Database Cleanup.

Testing Checklist After Changing wp-config.php

After changing performance constants, test the store immediately.

• Homepage loads.
• Shop page loads.
• Product page loads.
• Variable product page works.
• Add to cart works.
• Cart updates correctly.
• Checkout loads.
• Payment gateways appear.
• Test order works.
• Order email sends.
• Customer login works.
• Admin order screen loads.
• Scheduled actions run.
• No public PHP errors appear.
• Error logs do not show new fatal errors.

If anything breaks, restore the previous wp-config.php backup first. Then reapply one constant at a time.

Common Mistakes

• Adding DISABLE_WP_CRON without setting up server cron.
• Turning on WP_CACHE without WooCommerce-safe cache exclusions.
• Leaving SAVEQUERIES enabled on production.
• Using huge memory limits to hide plugin problems.
• Setting EMPTY_TRASH_DAYS to 0 and losing recovery time.
• Disabling revisions completely on a team-managed store.
• Editing wp-config.php without a backup.
• Adding duplicate constants with different values.
• Not testing checkout after config changes.

Final Verdict

The best wp-config.php constants for WooCommerce performance are the ones that improve stability without breaking dynamic store behavior. Start with memory limits, production-safe debugging, query logging off, revision limits, safe trash retention, and a real cron setup.

Use WP_CACHE only with a properly configured WooCommerce-safe caching system. Use DISABLE_WP_CRON only after server cron is ready. Use debugging constants only when troubleshooting. Use revision and autosave constants to reduce database noise without hurting your editing workflow.

For most WooCommerce stores, a clean wp-config.php is not a replacement for good hosting, caching, database cleanup, image optimization, and checkout testing. But it is an important foundation.

Use the FyrePress wp-config.php Builder to generate a safer baseline, then test every change on staging before applying it to a live revenue-generating store.