Як оптимізувати OpenCart: від 4 секунд до 400мс
Зміст
Стаття
Спершу виміряйте TTFB: до 0.5 с — причина у фронтенді, понад 1.5 с — на сервері.
- Найважчі запити покаже slow query log і pt-query-digest — найчастіше це oc_product, oc_product_description і oc_category_path.
- Composite-індекси на поля фільтрації, напр. (status, date_available), прибирають full table scan у категоріях.
- Nginx FastCGI cache знижує TTFB закешованих сторінок з 2–4 с до 10–50 мс.
- Redis замість дискового кешу прискорює динамічні сторінки на 30–50%, OPcache + JIT — ще на 10–20%.
Результат на магазині з 80k товарів: TTFB категорій 4200 → 380 мс, навантаження MySQL 240% → 18%.
Повільний OpenCart — одна з найпоширеніших проблем з якою стикаються власники інтернет-магазинів. У цій статті розберемо покроковий процес оптимізації від аналізу до результату.
Спершу зрозумійте, що саме гальмує
Оптимізувати навмання — найдорожчий шлях. Спочатку треба розділити дві різні речі: сервер довго віддає сторінку чи браузер довго її малює.
Перше видно як високий TTFB — час до першого байта. Якщо він великий, вина на боці сервера: база, PHP, відсутній кеш. Друге видно як довгий рендер при нормальному TTFB — тоді проблема у зображеннях, шрифтах і скриптах теми, і жодні налаштування MySQL її не виправлять.
Перевірити можна однією командою, без сторонніх сервісів:
curl -o /dev/null -s -w "ttfb=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/
Орієнтир: ttfb до 0.5 с — сервер здоровий, шукайте причину у фронтенді. Понад 1.5 с — далі за кроками нижче.
Крок 1: Аналіз slow query log
Перш за все увімкніть slow query log у MySQL/MariaDB:
slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 0.5
Використовуйте pt-query-digest для аналізу найважчих запитів. Найчастіше проблема в таблицях oc_product, oc_product_description та oc_category_path.
Крок 2: Індекси та запити
Додайте composite індекси на часто фільтровані поля. Типовий приклад — запити на сторінці категорії виконують full table scan через відсутній індекс на (status, date_available).
Крок 3: FastCGI Cache
Nginx FastCGI cache дає найбільший приріст для статичних сторінок. TTFB падає з 2-4 секунд до 10-50ms для закешованих сторінок. Налаштуйте виключення для кошика та адмінки.
Крок 4: Redis Object Cache
OpenCart підтримує Redis через стандартний cache driver. Замість дискового кешу session та object cache переключіться на Redis — це прискорює динамічні сторінки на 30-50%.
Крок 5: OPcache + JIT
PHP 8.x JIT компіляція дає 10-20% приросту для CPU-heavy операцій. Налаштуйте opcache.memory_consumption=256 і opcache.jit_buffer_size=64M.
Результат
Після комплексної оптимізації реального магазину з 80k товарів: TTFB категорій 4200ms → 380ms, MySQL CPU 240% → 18%.
Що робити далі
Описане вище закриває більшість типових випадків, але два моменти варто врахувати окремо.
Якщо TTFB лишається високим після кешування — справа не в магазині, а в сервері: кількість PHP-воркерів, налаштування бази, повільний диск. Порядок діагностики описаний у матеріалі чому сервер повільний.
Якщо потрібен результат, а не експерименти — є послуга оптимізації швидкодії OpenCart з вимірюванням до і після. Суміжне: Redis-кешування та налаштування Nginx і PHP-FPM.
Коли оптимізація вже не допоможе
Є межа, за якою налаштування вичерпані. Якщо кеш увімкнено, база проіндексована, а магазин усе одно впирається у ресурси в пікові години — питання вже не в конфігурації, а в тарифі чи сервері. Коли переїзд справді виправданий, розібрано в матеріалі shared чи VPS для магазину.
Окремий випадок — повільна адмінка при швидкій вітрині. Там інші причини й інші рішення: чому гальмує адмінка OpenCart.
Матеріали кластера
- Redis-кешування в OpenCart — детально до кроку 4.
- Nginx і PHP-FPM під навантаження — скільки воркерів насправді потрібно.
- PageSpeed 90+ — фронтендова частина, якої немає в цьому тексті.
- Core Web Vitals — метрики, за якими оцінює Google.
- Повільна адмінка — окремий сценарій.
Часті запитання
Як зрозуміти, що гальмує саме сервер, а не тема?
Виміряйте TTFB — час до першого байта, наприклад командою curl зі статті. До 0.5 с сервер здоровий, і причину треба шукати у зображеннях, шрифтах і скриптах теми. Понад 1.5 с — вина на боці сервера: база, PHP, відсутній кеш.
З чого почати оптимізацію бази OpenCart?
Увімкніть slow query log (long_query_time = 0.5) і розберіть найважчі запити через pt-query-digest. Найчастіше проблема в таблицях oc_product, oc_product_description і oc_category_path, а лікується composite-індексами на поля, за якими фільтрують, — наприклад, (status, date_available).
Що дає найбільший приріст швидкості?
Для сторінок, які можна закешувати, — Nginx FastCGI cache: TTFB падає з 2–4 секунд до 10–50 мс (кошик і адмінку треба виключити). Для динамічних сторінок — Redis замість дискового кешу (+30–50%) і OPcache з JIT (+10–20%).
Що робити, якщо після кешування TTFB лишається високим?
Тоді справа вже не в магазині, а в сервері: кількість PHP-воркерів, налаштування бази, повільний диск. Якщо кеш і індекси на місці, а магазин усе одно впирається в ресурси в пікові години, — питання в тарифі чи сервері: shared чи VPS для магазину.
