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

Ми бачимо типову картину після кількох років розвитку бітрікс-проєкту: TTFB 800–1200 мс, Largest Contentful Paint за 4 секунди, PageSpeed Insights у червоній зоні. Причини зазвичай не в хостингу — вони всередині самого застосунку: некешовані компоненти, неоптимізовані запити до інфоблоків, 200+ HTTP-запитів на сторінку через незібрані JS/CSS та зображення без стиснення, що завантажуються в оригінальному розширенні. За даними Google, збільшення LCP з 2,5 до 5 секунд підвищує ймовірність відмов на 90%. Для магазину на Бітрікс кожна секунда затримки може коштувати значних втрат продажів. Практика показує, що комплексна оптимізація 1С-Бітрікс — не одна дія, а послідовне усунення кількох класів проблем. Порядок важливий: спочатку серверна сторона, потім фронтенд. При грамотному підході вдається знизити TTFB у 3-5 разів за перший тиждень, а PageSpeed піднімається з червоної зони в зелену. Нещодавно на проєкті з 15 000 SKU ми за тиждень знизили TTFB з 1,4 с до 180 мс — детальніше в кейсі. Оцінимо ваш проєкт — зв'яжіться з нами. Вартість базового аудиту — 5 000 грн, комплексна оптимізація — від 20 000 грн. Ми маємо 10+ років досвіду в оптимізації Бітрікс та виконали понад 50 проєктів.

Ціна повільного сайту: вплив на конверсію та SEO

Швидкість завантаження прямо впливає на конверсію та позиції у пошуковій видачі. 53% користувачів ідуть, якщо сторінка завантажується довше 3 секунд. Для інтернет-магазинів на Бітрікс кожна секунда завантаження каталогу може призводити до втрат конверсії. Наші клієнти після оптимізації фіксують зростання конверсії мобільного трафіку на 20–30%.

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

Кешування компонентів — перше, з чого починається будь-який аудит. У Бітрікс кожен компонент керує своїм кешем через параметр 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. Кешування запитів покращує TTFB у 2-4 рази швидше, ніж безконтрольне виконання.

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

Як композитний режим прискорює сайт і коли не допомагає?

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

Але композит не працює автоматично. Потрібна розмітка динамічних зон тегом 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.

Як ми досягли TTFB 180 мс за тиждень?

Один з наших клієнтів — корпоративний інтернет-магазин з 15 000 SKU на Бітрікс «Бізнес», 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 с. Конверсія мобільного трафіку зросла — користувачі перестали йти з повільних сторінок каталогу. Композит прискорив TTFB у 10 разів порівняно з початковим станом. Оптимізований сайт завантажується в 5 разів швидше, ніж неоптимізований.

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

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

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

По темі продуктивності веб-застосунків варто вивчити Wikipedia. Для максимальної швидкості рекомендується налаштувати опкодний кеш (OPcache) та використовувати Redis для кешування сесій та кешу даних.

Порівняння методів оптимізації

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

• Повний аудит продуктивності зі звітом по кожному вузькому місцю
• Виправлення кешування компонентів та налаштування тегованого кешу
• Оптимізація запитів до БД (перехід на D7, усунення N+1)
• Налаштування композитного режиму з розміткою динамічних зон
• Фронтенд-оптимізація: збірка CSS/JS, WebP, lazy load, minification
• Переведення агентів на cron та моніторинг їх виконання
• Навантажувальне тестування та фіксація метрик
• Документація щодо підтримки досягнутої швидкості

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

Терміни орієнтовні та залежать від обсягу кастомного коду. Рекомендується проводити регулярні аудити. Ми гарантуємо об'єктивну оцінку та прозорий план робіт. Отримайте консультацію — розкажіть про ваш проєкт, і ми підберемо оптимальне рішення. Зв'яжіться з нами, щоб замовити аудит. Наша послуга включає оптимізацію швидкості 1С-Бітрікс та прискорення сайту Бітрікс з використанням композитного режиму Бітрікс.

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

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

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.