Оптимізація кількості HTTP-запитів 1С-Бітрікс

Оптимізація кількості HTTP-запитів 1С-Бітрікс

Ми на аудитах Бітрікс-проектів регулярно зустрічаємо сторінку з 180–250 HTTP-запитами при завантаженні. Це не перебільшення: кожен компонент може додати 2–4 CSS-файли і 3–5 JS-файлів, плюс іконки як окремі PNG, плюс трекери аналітики, плюс віджети. Кожен запит — це DNS-резолюція, TCP-з'єднання (тристороннє рукостискання), TLS-узгодження (якщо HTTPS), заголовки відповіді. При HTTP/1.1 браузер тримає 6 паралельних з'єднань на домен; надлишкові з'єднання блокують критичний шлях рендерингу. При HTTP/2 мультиплексування допомагає, але не усуває накладні витрати через блокування HOL (head-of-line blocking). Досвід 10+ років у розробці на Бітрікс показує, що замовники часто не підозрюють, скільки зайвих запитів генерує типовий шаблон. Ми готові провести аудит і знизити кількість запитів у 2–3 рази, заощаджуючи бюджет на підтримку сайту. Вартість оптимізації: базова – від 8000 грн (економія до 30% часу завантаження), середня – від 15000 грн (економія до 50%), повна – від 25000 грн (економія до 70%).

Чому оптимізація HTTP-запитів критична для швидкості?

Кількість запитів — один із ключових факторів, що впливають на LCP (Largest Contentful Paint). Кожен зайвий запит подовжує критичний шлях рендерингу через послідовне завантаження ресурсів. Навіть із HTTP/2, який дозволяє мультиплексування, численні запити викликають конкуренцію за пропускну здатність і збільшують накладні витрати на обробку. Згідно з Wikipedia, скорочення запитів критичне для мобільних мереж.

Аудит поточного стану

Перший крок — заміряти, не вгадувати. Інструменти:

• Chrome DevTools → Network: колонки Requests, Transferred, DOMContentLoaded, Load
• WebPageTest — водоспад з групуванням за типами
• Lighthouse: метрика «Serve static assets with an efficient cache policy» + «Avoid chaining critical requests»

На водоспаді типова картина: HTML → CSS (×5) → шрифти (×6) → JS (×8) → зображення (×40+) → Ajax-запити компонентів (×3-5). Ми аналізуємо кожен ланцюжок і шукаємо точки скорочення. Гарантуємо, що після оптимізації кількість запитів не перевищить 100 для типового каталогу.

Зменшення запитів іконок за допомогою SVG-спрайтів

Кожна іконка як окремий файл — найшвидший спосіб отримати 30–50 зайвих запитів. CSS-спрайт (одне велике зображення) зменшує запити в 40 разів порівняно з окремими PNG. На практиці краще SVG-спрайт:

<!-- sprite.svg -->
<svg xmlns="http://www.w3.org/2000/svg">
    <symbol id="icon-cart" viewBox="0 0 24 24">...</symbol>
    <symbol id="icon-search" viewBox="0 0 24 24">...</symbol>
</svg>

<!-- використання -->
<svg><use href="/local/templates/main/img/sprite.svg#icon-cart"></use></svg>

Один HTTP-запит для всієї іконографії сайту. Кешується надовго. Inline SVG через PHP-хелпер — 0 запитів, але збільшує розмір HTML. Вибір залежить від кількості іконок на першому екрані. SVG-спрайт у 40 разів ефективніший з точки зору кількості запитів, ніж окремі PNG-файли.

Об'єднання CSS і JS без втрати функціональності

Вбудований комбайнер Бітрікс

У налаштуваннях головного модуля є «Об'єднувати CSS-файли» та «Об'єднувати JS-файли». Комбайнер об'єднує файли в один запит. Він працює, але є нюанси:

• Об'єднує лише файли з AddCSS() / AddHeadScript(), але не inline-стилі компонентів.
• При інвалідації кешу hash змінюється — браузери завантажують заново.
• Не мініфікує CSS/JS — лише конкатенація.

Webpack/Vite для кастомних ресурсів

Для власного коду налаштовуємо бандлер:

// vite.config.js
export default {
    build: {
        rollupOptions: {
            input: {
                main: 'local/templates/main/src/main.js',
                catalog: 'local/templates/main/src/catalog.js',
            }
        }
    }
}

Отримуємо 2 бандли замість 15+ окремих файлів. Об'єднання файлів зменшує запити в 3-5 разів.

Як зменшити кількість Ajax-запитів?

Компоненти Бітрікс з 'AJAX_MODE' => 'Y' роблять окремий XHR при переході між сторінками каталогу. Це нормально, але при ініціалізації сторінки часто бачимо кілька паралельних Ajax-запитів. Рішення — batching: об'єднати кілька запитів в один через чергу:

const queue = [];
function batchRequest(params) {
    queue.push(params);
    if (queue.length === 1) {
        setTimeout(() => {
            const batch = [...queue];
            queue.length = 0;
            fetch('/api/batch', {
                method: 'POST',
                body: JSON.stringify(batch)
            });
        }, 50);
    }
}

На стороні сервера — endpoint /api/batch, який диспетчеризує запити та повертає масив відповідей. Сертифіковані спеціалісти Бітрікс гарантують коректну інтеграцію. Batch-механізм у 5 разів зменшує кількість Ajax-запитів під час навігації.

Зображення: lazy loading та sprites

Зображення в каталозі — найбільше джерело запитів. Обов'язковий мінімум:

echo '<img src="' . $arItem['PREVIEW_PICTURE']['SRC'] . '"
           loading="lazy"
           width="' . $arItem['PREVIEW_PICTURE']['WIDTH'] . '"
           height="' . $arItem['PREVIEW_PICTURE']['HEIGHT'] . '"
           alt="' . htmlspecialchars($arItem['NAME']) . '">';

loading="lazy" — нативний lazy loading. Браузер не запитує зображення нижче viewport до скролу. На сторінці каталогу з 48 картками це прибирає 30–40 запитів з критичного шляху.

Вимірювання результатів оптимізації

Для оцінки використовуємо метрики: загальна кількість запитів, Load Time та LCP. Приклад із практики: клієнт — інтернет-магазин електроніки на Бітрікс. Головна сторінка — 214 HTTP-запитів, Load time 8,3 с. Після наших дій: ввімкнення CSS/JS комбайнера, SVG-спрайт із 64 іконок, loading="lazy" для зображень нижче fold, перенесення трекерів на defer, об'єднання кастомних JS через Vite, ввімкнення компресії Brotli та HTTP/2 Push. Підсумок: 214 → 88 запитів, Load time: 8,3 с → 3,1 с, LCP: 5,2 с → 1,9 с.

Згідно з Wikipedia, скорочення запитів критичне для мобільних мереж. Зауважте, що HTTP/2 Push вимагає правильної конфігурації сервера, щоб уникнути надлишкового використання пропускної здатності.

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

• Аудит поточної кількості запитів і водоспаду завантаження.
• Ввімкнення вбудованого комбайнера, налаштування кешування.
• Збірка SVG-спрайту та заміна іконок.
• Налаштування Vite/Webpack для кастомних ресурсів.
• Реалізація batch-механізму для Ajax.
• Додавання loading="lazy" та оптимізація зображень.
• Деплой HTTP/2 Push.
• Документація за результатами, навчання вашої команди.
• Підтримка після оптимізації 1 місяць.

Ми — команда з 10+ роками досвіду, реалізували понад 50 проектів на Бітрікс. Ми виконаємо оптимізацію під ключ за 14 днів. Напишіть нам, ми оцінимо ваш проект безкоштовно. Входить: аудит, комбайнер, спрайти, lazy loading, batch, HTTP/2 Push, документація.

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 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.