Прискорення 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

Як налаштувати Redis для MODX: покрокова інструкція

1. Встановіть пакет Redis через менеджер пакетів MODX (наприклад, Redis від modmore).
2. Внесіть зміни в config.inc.php, як показано вище.
3. У системних налаштуваннях MODX встановіть cache_resource_handler в xPDORedisCache.
4. Очистіть існуючий кеш через адміністративну панель.
5. Перевірте, що Redis сервер запущений і доступний на 127.0.0.1:6379.
6. Протестуйте швидкість завантаження сторінки — зазвичай TTFB падає в 2-3 рази.

Конфігурація Nginx для MODX

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;
}

Індекси бази даних

MODX не додає всі потрібні індекси автоматично. Для сайтів з 10 000+ ресурсів додаємо:

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);

Після додавання індексів EXPLAIN SELECT на типовий запит getResources покаже ref замість ALL. Це знижує навантаження на сервер і економить до 40% ресурсів хостингу, що зменшує витрати на інфраструктуру.

Що входить в оптимізацію MODX під ключ?

У базову оптимізацію входить: аудит поточної конфігурації (логи, профілювання, EXPLAIN), налаштування Redis-кешу та перенесення файлового кешу, оптимізація PHP-FPM, OPcache, Nginx, додавання необхідних індексів у MySQL, стиснення CSS/JS та налаштування браузерного кешування, перевірка Core Web Vitals до та після, документація щодо внесених змін. Для складних випадків — переписування некешованих снипетів на кешовані. Гарантуємо покращення TTFB мінімум на 50%. Результати підтверджуються вимірами Core Web Vitals.

Терміни робіт

Базова оптимізація (кеш, PHP-FPM, nginx, індекси): 2–3 дні. Переведення некешованих снипетів на кешовані + аудит шаблонів: 3–5 днів залежно від кількості елементів. Перехід на Redis-кеш з тестуванням: 1 день додатково. Кожен етап фіксується вимірами.

Замовте аудит продуктивності MODX

Залиште заявку — ми безкоштовно проаналізуємо ваш сайт і запропонуємо план оптимізації. Гарантуємо результат: підтверджені виміри Core Web Vitals до та після. Зв'яжіться з нами, щоб почати. Оптимізація знижує витрати на інфраструктуру та прискорює сайт, що позитивно впливає на конверсію.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.