Оптимізація кількості 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 місяць.