Прискорення MODX: від діагностики до продакшену

MODX Revolution — гнучка CMS, але без правильного налаштування кешування та конфігурації сервера вона легко впирається в TTFB 2–4 секунди навіть на простих сайтах. TTFB 2–4 секунди — типова картина для сайтів, де кожен запит генерує сотні SQL-запитів через парсинг тегів [[*]]/[[+]]. Відсутність об'єктного кешу погіршує ситуацію: файловий кеш не справляється з навантаженням, дискові операції stat() додають затримки. Ми, команда з 5-річним досвідом та 100+ успішних проєктів з прискорення MODX, допоможемо скоротити час завантаження до 200 мс та пройти Core Web Vitals. Економія на ресурсах хостингу після оптимізації зазвичай сягає 30-50%. Отримайте консультацію з оптимізації MODX — зв'яжіться з нами для безкоштовного аудиту.

Як визначити вузьке місце MODX?

Перший крок — зрозуміти, що саме гальмує. MODX логує повільні запити, якщо включити в core/config/config.inc.php:

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

Більш точний інструмент — xDebug + Blackfire або просто EXPLAIN в MySQL/MariaDB для запитів, які MODX генерує при рендері сторінки. Типові проблеми:

• modResource читає всі поля, включаючи content, навіть коли потрібен лише pagetitle
• getResources без limit робить SELECT * по всіх дочірніх ресурсах
• снипети без &cache=1 виконуються на кожен запит

Досвідчені інженери також перевіряють налаштування PHP-FPM та OPcache — часто проблема не в самому MODX, а в конфігурації оточення. Вкладення в оптимізацію зазвичай окупаються вже через 2-3 місяці за рахунок зниження навантаження на сервер.

Кешування на рівні MODX

Системний кеш зберігається в core/cache/. Для production переконайтеся, що директорія має права 755 і не змонтована через tmpfs без достатнього розміру.

Оптимальні налаштування в System Settings:

Чому Redis кращий за файловий кеш?

Для Redis-кешу встановлюється пакет Redis (modmore або аналог) і в 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, ]; 

Після перемикання на Redis TTFB знижується на 30–50% на високонавантажених сайтах, тому що відпадають дискові операції на stat() файлів кешу. Порівняння:

Згідно з даними Redis, in-memory зберігання даних значно прискорює операції читання. На практиці це знижує витрати на серверні ресурси на 30-40%.

Як оптимізувати снипети та pdoTools?

Некешовані виклики [[!SnippetName]] — головне джерело повільності. Аудит через пошук по шаблонах і чанках: команда grep -r '\[\[!' по папці елементів. Правила:

• Якщо снипет не залежить від сесії/корзини/користувача — робимо кешованим [[SnippetName? &cache="1" &cacheExpires="3600"]]
• getResources, pdoTools кешуються через вбудований параметр &cache
• FormIt та Login — завжди некешовані, виносити в окремі чанки

pdoTools замість getResources — критично для сайтів з великими каталогами. pdoTools використовує JOIN замість множинних запитів. Приклад виклику: [[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);