Оптимизация количества HTTP-запросов 1С-Битрикс
Мы на аудитах Битрикс-проектов регулярно встречаем страницу с 180–250 HTTP-запросами при загрузке. Это не преувеличение: каждый компонент может добавить 2–4 CSS-файла и 3–5 JS-файлов, плюс иконки как отдельные PNG, плюс трекеры аналитики, плюс виджеты. Каждый запрос — это DNS, TCP, TLS, заголовки ответа. При HTTP/1.1 браузер держит 6 параллельных соединений на домен. При HTTP/2 мультиплексирование помогает, но не устраняет накладные расходы полностью. Опыт 10+ лет в разработке на Битрикс показывает, что заказчики часто не подозревают, сколько лишних запросов генерирует типовой шаблон. Мы готовы провести аудит и снизить число запросов в 2–3 раза, экономя бюджет на поддержку сайта. Стоимость оптимизации рассчитывается индивидуально в зависимости от масштаба.
Аудит текущего состояния
Первый шаг — замерить, не угадывать. Инструменты:
- 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 для типового каталога.
Как объединить CSS и JS без потери функциональности?
Встроенный комбайнер Битрикс
В настройках главного модуля (/bitrix/admin/settings.php?lang=ru) есть «Объединять CSS-файлы» и «Объединять JS-файлы». Комбайнер объединяет файлы в один запрос /bitrix/cache/css/[hash].css. Он работает, но есть нюансы:
- Объединяет только файлы из
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+ отдельных файлов. Разделение на main и catalog важно: не грузим JS каталога на статических страницах.
Как уменьшить число запросов иконок с помощью 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. Выбор зависит от числа иконок на первом экране.
Почему Ajax-запросы компонентов тормозят загрузку?
Битрикс-компоненты с 'AJAX_MODE' => 'Y' делают отдельный XHR при переходе между страницами каталога. Это нормально, но при инициализации страницы часто видим несколько параллельных Ajax-запросов к ajax.php с разными параметрами. Решение — batching: объединить несколько запросов в один через очередь:
// Накапливаем запросы за 50 мс, затем отправляем batch
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, который диспетчеризует запросы и возвращает массив ответов. Сертифицированные специалисты Битрикс гарантируют корректную интеграцию.
Изображения: lazy loading и sprites
Изображения в каталоге — крупнейший источник запросов. Обязательный минимум:
// В шаблоне компонента catalog.element
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. Итог: 214 → 88 запросов, Load time: 8,3 с → 3,1 с, LCP: 5,2 с → 1,9 с.
| Метрика | До | После |
|---|---|---|
| Количество HTTP-запросов | 214 | 88 |
| Load Time | 8.3 с | 3.1 с |
| LCP | 5.2 с | 1.9 с |
| CSS-файлов | 12 | 2 |
| JS-файлов | 15 | 3 |
Согласно Wikipedia, сокращение запросов критично для мобильных сетей.
Что входит в работу?
- Аудит текущего количества запросов и водопада загрузки.
- Включение встроенного комбайнера, настройка кэширования.
- Сборка SVG-спрайта и замена иконок.
- Настройка Vite/Webpack для кастомных ресурсов.
- Реализация batch-механизма для Ajax.
- Добавление loading="lazy" и оптимизация изображений.
- Деплой HTTP/2 Push (пример конфигурации Nginx:
add_header Link "...";). - Документация по результатам, обучение вашей команды.
- Поддержка после оптимизации 1 месяц.
| Масштаб | Состав | Срок |
|---|---|---|
| Базовый | Комбайнер, lazy loading, defer трекеров | 1–2 дня |
| Средний | SVG-спрайт, Vite-бандлинг кастомного кода, HTTP/2 | 4–7 дней |
| Полный | Batch API для Ajax, полный аудит и устранение всех избыточных запросов | 8–14 дней |
Свяжитесь с нами, чтобы начать оптимизацию вашего сайта. Закажите аудит и получите индивидуальные рекомендации. Гарантируем результат, закреплённый в договоре.







