MODX Optimization: From Diagnostics to Production

MODX Acceleration: From Diagnostics to Production

We integrate and optimize MODX Revolution to achieve lightning-fast performance. With 10+ years of experience and 100+ successful MODX acceleration projects, our team brings load times down to 200 ms and ensures Core Web Vitals pass. Hosting resource savings after optimization typically reach 30–50%, saving clients up to $500 per month on server costs. Get a consultation on MODX optimization—contact us for a free audit.

How to Identify MODX Bottlenecks

The first step is to understand what slows down. MODX logs slow queries if you enable it in core/config/config.inc.php:

define('MODX_CONFIG_KEY', 'config'); // in System Settings: // log_level = 4 (DEBUG) // log_target = FILE 

A more precise tool is xDebug + Blackfire or just EXPLAIN in MySQL/MariaDB for queries that MODX generates during page rendering. Typical problems:

• modResource reads all fields, including content, even when only pagetitle is needed
• getResources without limit runs SELECT * on all child resources
• Snippets without &cache=1 execute on every request

Experienced engineers also check PHP-FPM and OPcache settings—often the bottleneck is not MODX itself but the environment configuration. Optimization investments usually pay back within 2–3 months by lowering server load.

Caching at the MODX Level

System cache is stored in core/cache/. For production, ensure the directory has permissions 755 and is not mounted via tmpfs without sufficient size.

Optimal System Settings:

Why Redis Beats File Cache

For Redis cache, install the Redis package (modmore or similar) and add to core/config/config.inc.php:

$config_options = [ 'cache_path' => MODX_CORE_PATH . 'cache/', 'cache_default_handler' => 'xPDORedisCache', 'cache_xpdo_handler' => 'xPDORedisCache', 'redis_host' => '127.0.0.1', 'redis_port' => 6379, 'redis_db' => 0, ]; 

After switching to Redis, TTFB drops by 30–50% on high-traffic sites because disk stat() operations on cache files disappear. Comparison:

According to Redis, in-memory data storage significantly speeds up read operations. In practice, this cuts server resource costs by 30–40%.

Optimizing Snippets and pdoTools

Uncached calls [[!SnippetName]] are the main cause of slowness. Audit by searching templates and chunks: grep -r '\[\[!' across the elements folder. Rules:

• If a snippet does not depend on session/cart/user — make it cacheable: [[SnippetName? &cache="1" &cacheExpires="3600"]]
• getResources, pdoTools are cached via the built-in &cache parameter
• FormIt and Login — always uncached, move to separate chunks

pdoTools instead of getResources is critical for sites with large catalogs. pdoTools uses JOIN instead of multiple queries, making it 3x faster than getResources on large data sets. Example call: [[pdoResources? &parents=15 &depth=2 &limit=20 &sortby=publishedon &sortdir=DESC &cache=1 &cacheExpires=1800]]

; /etc/php/8.1/fpm/conf.d/10-opcache.ini opcache.enable=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=10000 opcache.validate_timestamps=0 opcache.revalidate_freq=0 opcache.fast_shutdown=1 ; /etc/php/8.1/fpm/pool.d/modx.conf [modx] pm = dynamic pm.max_children = 20 pm.start_servers = 5 pm.min_spare_servers = 3 pm.max_spare_servers = 8 pm.max_requests = 500 request_terminate_timeout = 30s 

server { location ~* \.(js|css|png|jpg|webp|woff2|ico|svg)$ { expires 1y; add_header Cache-Control "public, immutable"; access_log off; } location ^~ /core/ { deny all; } gzip on; gzip_types text/plain text/css application/json application/javascript image/svg+xml; gzip_min_length 1024; gzip_comp_level 5; } 

ALTER TABLE modx_site_content ADD INDEX idx_parent_published (parent, published), ADD INDEX idx_context_published (context_key, published), ADD INDEX idx_publishedon (publishedon);