HTTP/2, HTTP/3 и сжатие для интернет-магазина

Страница каталога магазина тянет за собой десятки ресурсов: картинки товаров, стили, скрипты, шрифты. На старом HTTP/1.1 браузер выкачивает их почти по очереди, упираясь в лимит параллельных соединений, — и посетитель смотрит на полупустую страницу лишние секунды. А каждая секунда задержки — это упавшая конверсия и просевшие позиции в поиске. Хорошая новость: значительную часть этой задержки убирают на уровне транспорта, почти не трогая код.

В этой статье разберём, как ускорить интернет-магазин на 1С-Битрикс средствами транспортного слоя: чем полезны HTTP/2 и HTTP/3, зачем нужен TLS, как настроить сжатие Gzip и Brotli, кэш статики и как всё это влияет на Core Web Vitals. Заодно покажем, почему кривая настройка транспорта плодит ошибки 5xx и как этого избежать — если такие ошибки уже мучают, поможет услуга исправления HTTP-ошибок 500, 404, 403, 502, 504.

Почему транспорт влияет на скорость магазина

Скорость страницы складывается из двух больших частей: как быстро сервер сгенерирует ответ (бэкенд) и как быстро браузер получит и отрисует все ресурсы (доставка). Транспортный слой — HTTP-версия, TLS, сжатие, кэш — отвечает за вторую часть. Для магазина она особенно значима: каталог и карточка товара — это «тяжёлые» страницы с большим числом ресурсов.

Причём улучшения транспорта почти бесплатны с точки зрения кода: вы не переписываете шаблоны и компоненты, а меняете настройки веб-сервера и инфраструктуры. Поэтому это первый и самый выгодный шаг оптимизации — быстрый выигрыш без риска сломать бизнес-логику.

HTTP/1.1 и его узкие места

Чтобы понять ценность HTTP/2, надо увидеть ограничения предшественника. HTTP/1.1 был спроектирован под простые страницы, а не под современный магазин:

• Мало параллелизма. Браузер держит ограниченное число соединений к домену и качает ресурсы почти по очереди.
• Накладные расходы на соединения. Каждое новое соединение — это лишние затраты на установку.
• Раздутые заголовки. В каждом запросе повторяются одни и те же заголовки без сжатия.
• Костыли обхода. Спрайты, склейка файлов, домены-шарды — всё это придумали, чтобы обойти лимиты HTTP/1.1.

Именно эти узкие места и убирает HTTP/2, делая многие старые «оптимизации» ненужными или даже вредными.

Что даёт HTTP/2

HTTP/2 переработал транспорт, оставив ту же семантику запросов. Ключевые улучшения для магазина:

• Мультиплексирование. По одному соединению одновременно летят десятки запросов и ответов — без очереди и лимитов HTTP/1.1.
• Сжатие заголовков. Повторяющиеся заголовки сжимаются (HPACK), экономя трафик.
• Приоритеты ресурсов. Важное (стили, критичные скрипты) можно доставлять раньше второстепенного.
• Одно соединение. Меньше накладных расходов на установку множества соединений.

HTTP/3 и QUIC: следующий шаг

HTTP/2 решил параллелизм на уровне приложения, но остался поверх TCP — и унаследовал его проблему: потеря одного пакета блокирует все потоки в соединении (head-of-line blocking на транспорте). HTTP/3 переносит всё на QUIC поверх UDP и устраняет эту блокировку: потеря пакета в одном потоке не тормозит остальные.

Для магазина главный выигрыш — мобильные и нестабильные сети, где потери пакетов обычны, а доля мобильного трафика огромна. HTTP/3 обычно включают как дополнение к HTTP/2 (браузер сам выбирает лучший доступный протокол), а не вместо него. Требуется поддержка на стороне сервера или CDN и корректная настройка сертификатов.

TLS как обязательное условие

И HTTP/2, и HTTP/3 на практике работают только по HTTPS: браузеры согласуют версию протокола через TLS (механизм ALPN). Без корректного сертификата вы просто останетесь на HTTP/1.1, сколько бы ни включали HTTP/2 на сервере.

Для магазина HTTPS обязателен и без всякого HTTP/2 — это оплата, персональные данные, доверие и требования платёжных систем. Поэтому порядок неизменен: сначала правильно настроенный и актуальный TLS-сертификат (с автопродлением, без ошибок цепочки и смешанного контента), затем HTTP/2 и HTTP/3 поверх него.

Сжатие: Gzip и Brotli

Сжатие уменьшает объём передаваемых текстовых ресурсов — HTML, CSS, JS — прямо на лету. Это один из самых дешёвых способов ускорения, особенно на мобильных, где канал уже.

Оптимальная стратегия — включить оба: Brotli для браузеров, которые его поддерживают, и Gzip как надёжный запасной вариант. Для статики (CSS, JS) выгодно предварительно сжать файлы на высоком уровне и отдавать готовые, а динамический HTML сжимать на лету на умеренном уровне, чтобы не грузить процессор.

Кэш статики и заголовки

Самый быстрый ресурс — тот, который браузер вообще не запрашивает повторно. Кэширование статики через HTTP-заголовки убирает лишние скачивания CSS, JS, шрифтов и картинок при повторных визитах.

• Длинный срок кэша. Статике с версионированием в имени задают долгий срок жизни кэша.
• Версионирование по хешу. Меняется файл — меняется имя (или параметр), поэтому долгий кэш безопасен.
• Валидация. Заголовки условных запросов позволяют не качать неизменённое.
• Аккуратно с HTML. Динамический HTML не кэшируют надолго — только статику.

Кэш статики на транспортном уровне не путать с серверным кэшем Битрикса. Как устроены композит, теговый кэш и почему они дополняют кэш статики, мы разбирали в общих материалах по инфраструктуре — см. статью про инфраструктуру и BitrixVM.

Изображения — отдельная задача

Важный нюанс: Gzip и Brotli почти не сжимают JPEG, PNG и шрифты — эти форматы уже сжаты. А ведь изображения обычно самый тяжёлый ресурс магазина. Поэтому их оптимизируют отдельно:

• Современные форматы. WebP и AVIF заметно легче JPEG/PNG при том же качестве.
• Правильные размеры. Не грузить картинку 2000px, если показывается 400px.
• Ленивая загрузка. Изображения ниже экрана подгружаются по мере прокрутки.
• Адаптивные картинки. Разные размеры под разные экраны.

Сжатие текста и оптимизация изображений — разные слои, и для быстрого магазина нужны оба. Транспорт ускоряет доставку, но не уменьшит вес неоптимизированной картинки.

Влияние на Core Web Vitals

Все перечисленные меры напрямую бьют по метрикам скорости, которые входят в Core Web Vitals и учитываются поиском. HTTP/2 и HTTP/3 ускоряют доставку ресурсов, сжатие уменьшает их вес, кэш статики убирает повторные скачивания — вместе это улучшает LCP (время до отрисовки основного контента) и общее ощущение скорости.

Для магазина скорость — двойная выгода: это и фактор ранжирования, и прямой драйвер конверсии. Медленный магазин теряет и позиции, и покупателей на каждом шаге воронки. Транспорт закладывает фундамент, поверх которого работают кэш Битрикса и оптимизация фронтенда — как выстраивать полный конвейер выкладки без просадок скорости, мы описывали в статье про CI/CD и деплой в Битрикс.

Настройка на 1С-Битрикс

На типовом стеке 1С-Битрикс (Nginx + PHP-FPM, часто в связке BitrixVM) настройка транспорта сводится к понятной последовательности:

1. Настройте TLS. Актуальный сертификат с автопродлением, без ошибок цепочки и смешанного контента.
2. Включите HTTP/2. На фронтенд-сервере (Nginx) поверх HTTPS.
3. Добавьте HTTP/3. Если поддерживается сервером или CDN, как дополнение к HTTP/2.
4. Включите сжатие. Gzip и Brotli для текстовых типов, предварительное сжатие статики.
5. Настройте кэш статики. Долгий срок жизни для версионированных ресурсов.
6. Проверьте проксирование. Корректные таймауты и буферы между Nginx и PHP-FPM.
7. Измерьте результат. Синтетические тесты и полевые метрики скорости до и после.

Настройка обычно затрагивает конфигурацию веб-сервера и инфраструктуры, поэтому её выносят в управляемый и воспроизводимый процесс. Как хранить и раскатывать такие изменения без ручных правок на бою — в материале про CI/CD и деплой.

Ошибки 5xx при неверной настройке

Транспортные изменения — частый источник ошибок 5xx, если делать их наспех. При переходе на HTTP/2 или добавлении reverse-proxy без корректных таймаутов и буферов появляются 502 Bad Gateway и 504 Gateway Timeout, особенно на тяжёлых операциях.

Магазин на 1С-Битрикс к этому чувствителен: обмен с 1С, генерация большого каталога, экспорт — всё это долгие запросы, которые упираются в таймауты прокси. Поэтому при настройке транспорта обязательно согласуют таймауты между фронтендом и бэкендом. Если 5xx уже появляются, их разбор и устранение — это профильная услуга исправления HTTP-ошибок.

Частые ошибки

• Включили HTTP/2 без HTTPS. Браузеры остаются на HTTP/1.1, эффекта нет.
• Оставили хаки HTTP/1.1. Агрессивная склейка файлов и домены-шарды мешают мультиплексированию.
• Нет сжатия статики. CSS и JS отдаются несжатыми, вес страницы завышен.
• Пытаются «сжать» картинки Gzip. Нет эффекта — изображения оптимизируют отдельно.
• Короткий кэш статики. Браузер каждый раз перекачивает неизменные ресурсы.
• Неверные таймауты прокси. Тяжёлые операции обмена дают 502/504.
• Считают транспорт панацеей. Быстрый транспорт не спасает медленный бэкенд и неоптимизированные картинки.

Чек-лист внедрения

1. TLS настроен. Актуальный сертификат, автопродление, нет смешанного контента.
2. HTTP/2 включён. Проверено, что браузер реально работает по HTTP/2.
3. HTTP/3 добавлен. Если поддерживается инфраструктурой или CDN.
4. Сжатие работает. Gzip и Brotli для текста, статика сжата предварительно.
5. Кэш статики настроен. Долгий срок для версионированных ресурсов.
6. Картинки оптимизированы. Современные форматы, размеры, ленивая загрузка.
7. Таймауты согласованы. Между фронтендом и PHP, нет 502/504 на тяжёлых операциях.
8. Скорость измерена. Метрики до и после, контроль Core Web Vitals.

Вывод

HTTP/2, HTTP/3 и сжатие — это фундамент скорости магазина, который окупается почти без изменений кода. Мультиплексирование HTTP/2 убирает очередь ресурсов, HTTP/3 добавляет устойчивость на мобильных сетях, а Gzip и Brotli с кэшем статики снижают вес и повторные скачивания. Всё это прямо улучшает Core Web Vitals, а значит и позиции, и конверсию.

Но транспорт — не панацея: он ускоряет доставку, а не генерацию страниц и не вес картинок. Стройте скорость слоями: правильный TLS и HTTP/2/3, сжатие и кэш статики, затем серверный кэш Битрикса и оптимизация изображений. И делайте настройку аккуратно — согласованные таймауты прокси уберут ошибки 502 и 504, которые часто приходят вместе с переходом на новый транспорт.