Комплексна оптимізація Magento 2 під ключ

Ми стикалися з ситуацією: Magento 2 завантажує сторінку 8 секунд, кожен запит викликає 300 SQL-запитів та 60 файлових операцій. Клієнти йдуть, конверсія падає. Рішення — не просто ввімкнути кеш, а вибудувати правильний стек: CDN → Varnish → Nginx → PHP-FPM 8.2 → MySQL 8.0, кожен шар налаштований під платформу. За 6–10 робочих днів ми доводимо TTFB до 200–500 мс. У цій статті — перевірені методи та конфігурації, які використовуємо на комерційних проєктах.

Нещодавній кейс: магазин з каталогом 50 000 SKU на shared хостингу — сторінка завантажувалася 12 секунд, LCP — 8 секунд. Аудит показав, що плагін «Featured Products» робив 150 SQL-запитів на сторінку. Після налаштування Varnish та усунення N+1 TTFB знизився до 0.3 с, LCP — до 1.2 с. Порівняння: Varnish кращий за вбудований кеш Magento в 10 разів по TTFB, а Redis скорочує час генерації блоку з 50 мс до 1–2 мс.

Чому Magento 2 гальмує?

Стандартне встановлення виконує 200–400 SQL-запитів та 50–100 файлових операцій на сторінку. Типові причини:

• N+1 проблеми — плагіни afterLoad, колекції без addAttributeToSelect, завантаження продуктів по одному.
• Відсутність Varnish — динамічний контент генерується при кожному запиті.
• MySQL без налаштування — буфер за замовчуванням 128 МБ, redo log 48 МБ.
• PHP без OPcache/JIT — інтерпретація коду на кожен запит.
• Пошук через MySQL — LIKE '%query%' для каталогу 10 000+ SKU дає 2–5 секунд.

Як ми налаштовуємо стек?

Varnish

Varnish — зворотний проксі-кеш, який зберігає повні HTTP-відповіді. Для анонімних користувачів hit rate досягає 85–95%. Конфігурація VCL враховує архітектуру Magento: пропускаємо сесії, корзину, checkout, кешуємо все інше.

Redis

Redis використовується для кешу (config, layout, block HTML, full page cache) та зберігання сесій. Це прибирає дискові операції та знижує навантаження на MySQL. Налаштування включає окремі інстанси для різних типів даних.

PHP 8.2 + OPcache + JIT

Перехід на PHP 8.2 дає приріст 15–25% на CPU-bound операціях. OPcache з пам'яттю 512 МБ та JIT в режимі tracing прискорюють виконання скриптів до 20%.

; /etc/php/8.2/fpm/conf.d/opcache.ini opcache.enable=1 opcache.memory_consumption=512 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=60000 opcache.validate_timestamps=0 opcache.revalidate_freq=0 opcache.fast_shutdown=1 opcache.enable_cli=1 ; JIT opcache.jit=tracing opcache.jit_buffer_size=256M 

[magento] user = www-data group = www-data listen = /run/php/php8.2-fpm-magento.sock listen.backlog = 65535 pm = dynamic pm.max_children = 40 pm.start_servers = 10 pm.min_spare_servers = 5 pm.max_spare_servers = 20 pm.max_requests = 2000 php_admin_value[memory_limit] = 768M php_admin_value[max_execution_time] = 600 php_admin_value[opcache.file_cache] = /tmp/opcache 

MySQL

InnoDB buffer pool — 70% від RAM сервера. Redo log 1 ГБ, flush method O_DIRECT, query cache вимкнено (м'ютекс вбиває паралелізм). Нижче — типова конфігурація для сервера з 16 ГБ RAM.

[mysqld] innodb_buffer_pool_size = 8G innodb_buffer_pool_instances = 8 innodb_log_file_size = 1G innodb_log_buffer_size = 64M innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT innodb_read_io_threads = 16 innodb_write_io_threads = 16 innodb_thread_concurrency = 0 query_cache_type = 0 slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 

Elasticsearch

MySQL-пошук замінюємо на Elasticsearch — повнотекстовий пошук з релевантністю, автодоповнення, фасетна фільтрація. Після переіндексації сторінка пошуку з 50 000 товарів відповідає за 50–150 мс замість 2–5 секунд.

Що робити з N+1 запитами?