HTTP/2 и HTTP/3: ускорение сайта без переделки

Есть категория работ по скорости, где не нужно трогать вёрстку, переписывать шаблоны, ужимать картинки и спорить с разработчиками о размере JS-бандла. Нужно поменять три строки в конфигурации веб-сервера — и страница начнёт грузиться заметно быстрее просто потому, что браузер и сервер перестанут разговаривать на протоколе 1997 года. HTTP/2 и HTTP/3 меняют не содержимое сайта, а способ его доставки: как устанавливается соединение, сколько запросов идёт параллельно, что происходит при потере пакета в мобильной сети. Эффект получают все страницы сразу, включая те, до которых у вас никогда не дойдут руки. В этой статье разбираем механику протоколов без академизма: что реально ускоряется, что нет, как проверить свою версию за минуту и что включать на практике в рамках технической части SEO-продвижения.

Почему протокол вообще стал узким местом

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

Ограничение первое и главное: внутри одного TCP-соединения HTTP/1.1 умеет обрабатывать только один запрос за раз. Отправил запрос — жди ответа целиком, потом отправляй следующий. Это называется head-of-line blocking на уровне HTTP: один медленный ответ блокирует очередь за собой. Браузеры обошли ограничение единственным доступным способом — открывают несколько соединений параллельно. Но и здесь потолок: практически все браузеры держат не более 6 одновременных соединений на один хост.

Посчитайте сами. Сто ресурсов, шесть параллельных каналов — это минимум семнадцать последовательных «волн» загрузки. Каждая волна упирается в задержку сети: при пинге 40 мс до сервера только на ожидание уходит около 700 мс, и это без учёта времени генерации ответа и передачи данных. На мобильном интернете с пингом 120–150 мс арифметика становится совсем печальной.

Ограничение второе: каждое новое TCP-соединение стоит денег во времени. Тройное рукопожатие TCP — один круг до сервера и обратно. TLS-рукопожатие на HTTPS — ещё один-два круга в зависимости от версии протокола. То есть перед тем как отдать первый байт полезных данных, браузер тратит 2–3 RTT. Умножьте на шесть соединений, откройте вторую пачку соединений к шрифтовому CDN и к домену аналитики — и вы получите ощутимый пролог перед стартом отрисовки.

Ограничение третье: заголовки передаются текстом и не сжимаются. Cookie на 1,5 КБ, User-Agent, Accept, Referer — всё это отправляется полностью с каждым из сотни запросов. На странице с сотней ресурсов только служебная переписка съедает сотни килобайт исходящего трафика, а исходящий канал у пользователя обычно уже входящего.

HTTP/1.1 не «медленный». Он просто спроектирован под другой веб. Мы двадцать лет обходили его ограничения костылями — спрайтами, конкатенацией, шардингом. HTTP/2 и HTTP/3 убирают саму причину, из-за которой эти костыли понадобились.

Что изменил HTTP/2

HTTP/2 (RFC 7540, 2015; актуальная редакция — RFC 9113) сохранил всю семантику HTTP: те же методы, те же коды ответа, те же заголовки, те же URL. Изменился транспортный уровень — то, как данные упаковываются и передаются по проводу. Именно поэтому переход не требует переделки сайта: приложение о смене протокола даже не знает.

Бинарный фрейминг и мультиплексирование

Вместо текстовых сообщений HTTP/2 использует бинарные фреймы фиксированной структуры. Каждый фрейм помечен идентификатором потока (stream). Это позволяет разложить десятки запросов и ответов на фреймы, перемешать их и передать по одному-единственному TCP-соединению, а на другом конце собрать обратно. Очередь исчезает: браузер отправляет все запросы сразу, сервер отвечает по мере готовности, медленный ответ не блокирует быстрые.

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

Сжатие заголовков HPACK

HTTP/2 сжимает заголовки алгоритмом HPACK со статической и динамической таблицами. Повторяющиеся заголовки (а они повторяются почти полностью от запроса к запросу) передаются ссылкой на индекс в таблице вместо полного текста. Экономия на странице с сотней ресурсов и жирными cookie достигает десятков и сотен килобайт исходящего трафика — а именно исходящий канал чаще всего узкий у мобильного пользователя.

Приоритеты потоков

Раз всё летит в одном соединении, нужен способ сказать «стили важнее, чем картинка в футере». В HTTP/2 изначально была громоздкая схема с деревом зависимостей, которую серверы реализовывали по-разному. На практике её заменил механизм Extensible Priorities (RFC 9218) с простым заголовком Priority и параметрами срочности. Для владельца сайта это означает: полагаться на автоматику сервера можно, но управлять приоритетом критичных ресурсов лучше явно — через preload для шрифта и LCP-картинки и атрибут fetchpriority="high" на главном изображении.

Server Push, который не взлетел

Обещанная киллер-фича HTTP/2 — сервер сам отправляет браузеру файлы, не дожидаясь запроса. На практике оказалось, что сервер не знает, что уже лежит в кэше браузера, и push регулярно тратил трафик впустую. Chrome отключил поддержку по умолчанию ещё в 2022 году, остальные последовали. Не тратьте время на настройку Server Push. Его функцию сегодня выполняет ранний ответ 103 Early Hints: сервер, пока готовит основной ответ, успевает сказать браузеру, какие ресурсы начинать грузить.

HTTP/3 и QUIC: зачем понадобилась третья версия

HTTP/2 убрал блокировку очереди на уровне HTTP, но оставил её на уровне TCP. TCP гарантирует доставку данных строго по порядку: если один пакет потерялся, все последующие пакеты ждут его повторной передачи — даже если они относятся к совершенно другому потоку. То есть на HTTP/2 потеря одного пакета с фрагментом картинки из футера тормозит доставку CSS, который уже физически пришёл на устройство. И чем больше потоков в одном соединении, тем больнее бьёт каждая потеря.

На стабильном проводном интернете это незаметно. На мобильной сети с потерями 1–3% HTTP/2 в отдельных сценариях работает хуже, чем HTTP/1.1 с шестью независимыми соединениями, — потому что там потеря била только по одному из шести каналов.

HTTP/3 (RFC 9114) решает это радикально: он работает не поверх TCP, а поверх QUIC (RFC 9000) — транспортного протокола на базе UDP, в который встроены и надёжная доставка, и шифрование. Ключевые следствия:

• Независимые потоки. Потеря пакета тормозит только тот поток, к которому пакет относился. Остальные ресурсы продолжают доставляться.
• Одно рукопожатие вместо двух. TLS 1.3 встроен в QUIC: установление шифрованного соединения занимает 1 RTT вместо привычных 2–3.
• 0-RTT при повторном подключении. Браузер, который уже общался с сервером, может отправить первый запрос вместе с рукопожатием — данные уходят до того, как соединение формально установлено.
• Миграция соединения. Соединение опознаётся не парой IP-адресов, а Connection ID. Пользователь вышел из зоны Wi-Fi в мобильную сеть — соединение не рвётся и не поднимается заново. Для сайтов с длинными сессиями и мобильным трафиком это ощутимо.
• QPACK вместо HPACK. Сжатие заголовков переработано так, чтобы не создавать искусственных зависимостей между потоками.

Важный нюанс развёртывания: браузер не может знать заранее, что сайт умеет HTTP/3. Первое подключение идёт по HTTP/2, сервер в ответе присылает заголовок Alt-Svc: h3=":443"; ma=86400 — «я умею h3 на этом порту, запомни на сутки». Начиная со следующего запроса браузер пробует QUIC. Отсюда практический вывод: эффект HTTP/3 проявляется со второго визита, и это нормальное поведение, а не поломка настройки.

Кому переход даст много, а кому почти ничего

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

Ещё один трезвый ориентир: транспорт влияет на время доставки, а не на объём. Если у вас на главной лежит фоновая картинка на 3,2 МБ в формате PNG, то по HTTP/3 она приедет ровно такой же тяжёлой. Работа с весом ресурсов — отдельная задача, её механика разобрана в материале про оптимизацию изображений, а общий порядок работ по производительности — в статье о скорости загрузки сайта.

Как протокол связан с Core Web Vitals

Это тот вопрос, ради которого тему обычно и поднимают. Разберём по метрикам, без обещаний «зелёной зоны по щелчку».

TTFB — прямое влияние

Time to First Byte складывается из сетевой части (DNS, TCP, TLS) и серверной (генерация ответа). Протокол сокращает именно сетевую: HTTP/3 экономит один-два круга до сервера на рукопожатии, а при 0-RTT — фактически всё время установления соединения. При пинге 30 мс это десятки миллисекунд, при пинге 150 мс — уже 150–300 мс, что на мобильных заметно. TTFB формально не входит в тройку Core Web Vitals, но он является слагаемым LCP: пока не пришёл первый байт HTML, не начнётся ничего.

LCP — существенное влияние

Largest Contentful Paint — момент отрисовки самого крупного элемента, чаще всего главной картинки или заголовочного блока. Тут работают сразу три фактора: сокращение рукопожатия ускоряет старт, мультиплексирование позволяет запросить LCP-ресурс, не дожидаясь очереди, а приоритеты дают ему проехать вперёд остальных. На тяжёлых страницах с большим количеством ресурсов переход на HTTP/2 нередко сдвигает LCP на сотни миллисекунд — но только если сама картинка не весит четыре мегабайта и не грузится через три редиректа.

INP — влияние косвенное

Interaction to Next Paint измеряет отзывчивость на действия пользователя и определяется загрузкой основного потока браузера: сколько JavaScript парсится, компилируется и выполняется. Протокол доставляет скрипты быстрее, но выполняются они ровно столько же. Быстрая доставка тяжёлого бандла иногда даже ухудшает картину: браузер получает всё раньше и раньше уходит в блокирующее выполнение. Улучшение INP — это работа с кодом, а не с транспортом.

CLS — влияния практически нет

Cumulative Layout Shift зависит от того, зарезервировано ли место под изображения, баннеры и шрифты. Единственный косвенный плюс: при быстрой доставке шрифта короче окно, в котором виден подменённый шрифт. Всё остальное решается атрибутами width/height, font-display и резервированием контейнеров. Подробный разбор всех трёх метрик и порогов — в отдельном материале про Core Web Vitals.

Как проверить, на каком протоколе работает ваш сайт

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

Как включить: практическая сторона

Дальше — конкретика по типовым конфигурациям. Формулировки директив зависят от версии ПО, поэтому первым делом смотрите, что у вас установлено: nginx -v, apache2 -v, панель хостинга.

Обязательные проверки после включения

1. Синтаксис конфигурации. Перед перезапуском — nginx -t или apachectl configtest. Ошибка в директиве уронит все сайты на сервере, а не один.
2. Открытый UDP 443. Для HTTP/3 нужен именно UDP, не TCP. Забыть про правило файрвола — самая частая причина «включил, а не работает».
3. Alt-Svc в ответе. Без этого заголовка браузеры не узнают про h3. Проверяется одной командой curl.
4. Заголовок отдаётся на всех страницах. Если Alt-Svc добавлен только в один location, часть сайта останется на HTTP/2.
5. Все поддомены и статика. Проверьте домены с картинками, шрифтами и медиа: часто основной сайт переехал, а поддомен со статикой забыли.
6. Контрольный замер. Снимите метрики до и после на одинаковых условиях — один и тот же URL, одна сеть, режим инкогнито, несколько прогонов.

Приёмы эпохи HTTP/1.1, от которых пора избавиться

Двадцать лет мы боролись с ограничением в шесть соединений и дорогими рукопожатиями. Родившиеся из этой борьбы техники после перехода на HTTP/2 превращаются из оптимизации в тормоз. Это едва ли не самая ценная часть темы: включить протокол — полдела, вторая половина — убрать костыли, которые ему мешают.

Оговорка от практика: не бросайтесь дробить всё на атомы. Слишком мелкие файлы плохо сжимаются — gzip и brotli работают эффективнее на крупных объёмах, и триста файлов по 800 байт в сумме весят больше, чем десять по 24 КБ. Плюс каждый ресурс — это работа браузера по обработке. Здоровый ориентир: 10–20 файлов вместо одного монолита, но не двести.

Типичные проблемы внедрения и как их чинить

Собрали сценарии, которые встречаются на аудитах чаще всего, вместе с причинами и порядком действий.

Отдельно про безопасность

HTTP/2 принёс не только скорость. В 2023 году громко прозвучала атака Rapid Reset, эксплуатировавшая механику быстрого создания и отмены потоков: одно соединение позволяло сгенерировать шквал запросов. Все актуальные версии веб-серверов проблему закрыли, но вывод остаётся практическим: включая новый протокол, обновляйте сам веб-сервер, а не только конфиг. Работать на nginx пятилетней давности с включённым h2 — плохая идея. Заодно проверьте лимиты одновременных потоков в настройках; значения по умолчанию у современных сборок разумные, но у старых сборок их иногда поднимали вручную.

Что это значит для SEO и роботов

Здесь важно разделить два эффекта: влияние на пользователя и влияние на робота.

Обход и индексация

Google официально объявил о переходе на обход по HTTP/2 в конце 2020 года: краулер сам решает, использовать ли вторую версию, исходя из выгоды — и никакого преимущества в ранжировании за это не даёт. Смысл для сайта в другом: мультиплексирование снижает накладные расходы на соединения, а значит робот при том же ресурсе успевает загрузить больше. Для крупных каталогов, где краулинговый бюджет реально ограничивает индексацию, это дополнительный, пусть и не решающий, аргумент.

Про российский поиск честно: публичных заявлений о том, что основной индексирующий робот Яндекса массово ходит по HTTP/3, нет. Поэтому не стройте ожиданий вокруг обхода — стройте вокруг пользователей, а долю версий протокола в трафике робота посмотрите у себя в логах через $server_protocol, это займёт пять минут и даст точный ответ по вашему проекту.

Скорость как фактор ранжирования

И Яндекс, и Google учитывают скорость, но не так линейно, как хочется думать. Работает пороговая логика: катастрофически медленный сайт проигрывает, а между быстрым и очень быстрым разница в ранжировании небольшая. Гораздо надёжнее считать выигрыш через поведение: сокращение времени до первого экрана снижает отказы, а отказы — это уже вполне весомый сигнал в факторах ранжирования Яндекса. На мобильном трафике эффект выражен сильнее всего — там и RTT выше, и терпение пользователя короче, о чём подробно в материале про мобильную оптимизацию.

Деньги, а не позиции

Самый прикладной аргумент для владельца бизнеса — конверсия. Ускорение первого экрана на несколько сотен миллисекунд на мобильных устройствах даёт измеримый прирост доли пользователей, дошедших до карточки и корзины. Это не про SEO напрямую, это про то, что каждый уже оплаченный визит начинает приносить больше — механика подробно разобрана в статье про конверсию сайта. И в отличие от многих SEO-работ, здесь эффект наступает в день внедрения, а не через квартал.

Порядок работ: куда протокол встаёт в общем плане

Переход на новую версию HTTP — не первый и не последний шаг. Вот последовательность, в которой мы обычно разбираем производительность на проектах, от самого дешёвого к самому трудозатратному.

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

Мини-план внедрения за один рабочий день

Если хочется получить результат сегодня, а не через спринт, вот компактная последовательность.

1. Замерьте базу. Три прогона основных типов страниц (главная, категория, карточка, статья) на мобильном профиле, зафиксируйте TTFB и LCP. Без этого замера вы не докажете результат ни себе, ни клиенту.
2. Определите текущую версию по колонке Protocol — отдельно для документа, статики, шрифтов и сторонних скриптов.
3. Включите HTTP/2 там, где его нет: своя конфигурация, панель или переключатель CDN. Проверьте конфиг перед перезапуском.
4. Проверьте согласование ALPN и убедитесь, что все хосты проекта отвечают по h2.
5. Включите HTTP/3, если версия сервера позволяет, добавьте Alt-Svc, откройте UDP 443, проверьте со второго визита и с мобильной сети.
6. Уберите очевидные костыли HTTP/1.1: шардинг статики и base64 в критическом CSS дают эффект сразу и правятся без разработки.
7. Повторите замер в тех же условиях и сравните. Сохраните оба отчёта — это ваш аргумент в разговоре с бизнесом.
8. Поставьте мониторинг. Раз в месяц проверяйте, что протокол не отвалился после обновления панели или переезда: такое случается регулярно и молча.

Последний пункт недооценивают. Обновление панели хостинга, миграция на новый сервер, смена тарифа — любое из этих событий способно вернуть сайт на HTTP/1.1, и никто этого не заметит, пока кто-нибудь не откроет DevTools. Добавьте проверку версии протокола в регулярный технический чек-лист вместе с проверкой сертификата и robots.txt. Как выбрать площадку, на которой такие вещи не ломаются каждый квартал, разбирали в статье про хостинг и SEO.

Частые вопросы