Оптимізація швидкості завантаження сайту 1С-Бітрікс

Оптимізація швидкості завантаження сайту 1С-Бітрікс

Типова картина після кількох років розвитку бітрікс-проєкту: TTFB 800–1200 мс, Largest Contentful Paint за 4 секунди, PageSpeed Insights у червоній зоні. Причини зазвичай не в хостингу — вони всередині самого застосунку: некешовані компоненти, неоптимізовані запити до інфоблоків, 200+ HTTP-запитів на сторінку через незібрані JS/CSS та зображення без стиснення, що завантажуються в оригінальному розмірі.

Оптимізація 1С-Бітрікс — це не одна дія, а послідовне усунення кількох класів проблем. Кожен клас дає свій приріст, і важливо працювати в правильному порядку: спочатку серверна сторона, потім фронтенд.

Серверна сторона: кеш, запити, агенти

Кешування компонентів — перше, з чого починається будь-який аудит. У Бітрікс кожен компонент управляє своїм кешем через параметр CACHE_TYPE та CACHE_TIME. Часто зустрічається ситуація, коли розробники виставили CACHE_TYPE = N («без кешу») при налагодженні і забули повернути. Один такий компонент на головній сторінці — і TTFB зростає в рази.

Перевірка через \Bitrix\Main\Diag\Debug::dumpToFile() або модуль bitrix.performance показує список некешованих компонентів і час їх виконання. Стандартний інструмент — панель продуктивності (.../bitrix/admin/perfmon_panel.php).

Оптимізація запитів до БД. Інфоблоки Бітрікс при недбалому використанні генерують запити з SELECT * до b_iblock_element, b_iblock_element_property, b_iblock_section без обмеження по полях. Перехід на API D7 (Iblock\ElementTable) з явним зазначенням select знижує обсяг переданих даних і навантаження на MySQL. Окрема тема — проблема N+1: компонент у циклі робить запит для кожного елемента. Виявляється через $DB->ShowSqlStat() або MySQL slow query log з long_query_time = 0.1.

Агенти та фонові завдання. Агенти Бітрікс за замовчуванням виконуються в контексті веб-запиту, якщо не налаштований cron-режим. Це додає 50–300 мс до випадкових запитів. Переведення агентів на cron (/bitrix/modules/main/tools/cron_events.php) прибирає цю затримку повністю.

Композитний сайт: що реально пришвидшує і коли не допомагає

Композитний режим Бітрікс (bitrix.composite) кешує HTML сторінок у файловій системі і віддає їх без виконання PHP, замінюючи динамічні блоки (кошик, авторизація) через AJAX. Для контентних і каталожних сторінок це найпотужніший інструмент — TTFB падає до 20–50 мс.

Але композит не працює автоматично. Потрібне розмічення динамічних зон тегом bitrix:nocache, переведення авторизації та кошика на AJAX-компоненти, налаштування виключень для сторінок з персоналізацією. Неправильне налаштування призводить до того, що в кеші опиняються дані залогіненого користувача — критична помилка на проєктах з особистим кабінетом.

Фронтенд: HTTP-запити та вага ресурсів

Після серверної оптимізації дивимося на клієнтську частину через Chrome DevTools → Network. Типові проблеми бітрікс-проєктів:

• Незібрані CSS/JS: кожен модуль підключає свої файли окремо. На навантаженому проєкті це 30–80 файлів. Бітрікс вміє об'єднувати їх через налаштування стиснення (Налаштування → Продуктивність → Стиснення), але потребує коректного налаштування шляхів та HTTP/2.
• Зображення без оптимізації: оригінальні файли з медіабібліотеки роздаються без конвертації в WebP, без srcset для retina. Модуль resize_image дозволяє нарізати зображення «на льоту», але без налаштування кешу нарізки це створює навантаження.
• Відсутність lazy load: зображення нижче fold завантажуються разом з першим екраном. У Бітрікс це вирішується через атрибут loading="lazy" у шаблонах компонентів або JavaScript IntersectionObserver.

Кейс: корпоративний інтернет-магазин, 15 000 SKU

Проєкт на Бітрікс «Бізнес», PostgreSQL, VPS 4 CPU / 8 GB RAM. До оптимізації: PageSpeed Mobile — 22/100, TTFB — 1,4 с, LCP — 5,8 с. Скарги клієнтів на повільне завантаження каталогу.

Аудит виявив:

• 4 компоненти з CACHE_TYPE = N на головній (залишені розробником при дебагу)
• N+1 у компоненті «схожі товари» — 48 запитів на сторінці товару
• Агенти у веб-режимі, 11 агентів виконувалися синхронно
• 94 HTTP-запити на головній (CSS/JS не об'єднані)
• Зображення в JPEG без WebP, середній розмір 340 KB

Послідовність робіт:

1. Виправлення кешування компонентів → TTFB 1,4 с → 380 мс
2. Оптимізація N+1, перехід на D7 API → запитів на сторінці товару: 48 → 6
3. Переведення агентів на cron → прибрали 80–200 мс латентності
4. Об'єднання CSS/JS → HTTP-запитів: 94 → 18
5. WebP через CFile::ResizeImageGet() + lazy load → середня вага сторінки: 2,8 MB → 680 KB
6. Налаштування композитного режиму для каталогу та головної

Підсумок: PageSpeed Mobile 71/100, TTFB 180 мс, LCP 2,1 с. Конверсія мобільного трафіку зросла — користувачі перестали йти зі повільних сторінок каталогу.

Інструменти для самодіагностики

До звернення до спеціаліста можна самостійно перевірити:

• /bitrix/admin/perfmon_panel.php — вбудована панель продуктивності Бітрікс
• MySQL slow query log (long_query_time = 1) — повільні запити
• Chrome DevTools → Lighthouse — загальна картина по фронтенду
• Аналог php artisan у Бітрікс — php bitrix/modules/main/tools/cron_events.php для перевірки агентів

Етапи та терміни

Робота розбивається на аудит та усунення проблем за пріоритетами:

Терміни залежать від обсягу кастомного коду та кількості виявлених проблем.