HTTP/2 и HTTP/3 на хостинге: как проверить и что это даёт сайту
Чем новые версии протокола лучше, как узнать, что у вас включено, и почему после перехода часть старых оптимизаций стала вредной.
Содержание
HTTP/2 сегодня есть почти у всех хостингов, проверяется за минуту в инструментах разработчика. Куда важнее, что вместе с ним протухли старые приёмы: склейка всех стилей в один файл и спрайты из иконок теперь замедляют, а не ускоряют.
Клиент прислал отчёт от сеошника: «включите http2 на хостинге, сайт грузится в два раза дольше нормы». Открываю DevTools, а там уже h2, причём года три как. Зато в теме честно склеены двенадцать CSS-файлов в один мегабайтный монолит, потому что так советовали в 2014 году. Разберём, чем HTTP/2 и HTTP/3 отличаются от старого HTTP/1.1, как за минуту проверить свою версию, что делать, если хостинг застрял на прошлом протоколе, и какие приёмы оптимизации после перехода начали работать против вас.
Сразу оговорка, чтобы не создавать ложных ожиданий. Смена протокола это не волшебная кнопка «сайт стал быстрее в два раза». На типовом сайте услуг с тридцатью запросами выигрыш будет в районе сотни миллисекунд, и человек его не заметит. На магазине с полутора сотнями картинок и десятком скриптов разница уже честные полсекунды, а на мобильном интернете больше.
Что вообще поменялось
HTTP/1.1 родился в 1997 году и умел одну простую вещь: одно соединение, один запрос, ждём ответ, следующий запрос. Браузеры обходили это грубой силой, открывая по 6 параллельных соединений на домен. Отсюда весь пласт оптимизаций нулевых: чем меньше файлов, тем лучше, потому что каждый файл занимает место в очереди из шести.
HTTP/2 (2015 год) сделал мультиплексирование: по одному TCP-соединению одновременно идут десятки потоков, ответы приходят вперемешку и собираются на стороне браузера. Плюс бинарные фреймы вместо текста и сжатие заголовков алгоритмом HPACK. Последнее недооценивают: если у вас на каждый запрос летит 800 байт кук и User-Agent, на сотне запросов это 80 килобайт мусора, который HTTP/2 ужимает до единиц килобайт.
HTTP/3 (стандартизован в 2022 году, RFC 9114) поехал ещё дальше и выкинул TCP. Под ним лежит QUIC поверх UDP. Причина в том, что у HTTP/2 осталась одна болячка: мультиплексирование работает выше уровня TCP, а сам TCP по-прежнему требует строгого порядка пакетов. Потерялся один пакет, и все потоки внутри соединения ждут ретрансмита. Это называется head-of-line blocking на транспортном уровне, и на стабильном проводе он почти незаметен, а на мобильной сети с потерями пакетов бьёт очень чувствительно.
Что ещё умеет QUIC:
- рукопожатие TLS 1.3 совмещено с установкой соединения, вместо трёх RTT получается один, а при повторном визите бывает и 0-RTT,
- соединение живёт по идентификатору, а не по паре IP:порт, поэтому переход с Wi-Fi на LTE не рвёт загрузку,
- шифрование обязательно, незашифрованного QUIC не бывает.
Одну штуку из HTTP/2 стоит помянуть отдельно: Server Push. Идея была красивая, сервер сам досылает CSS до того, как браузер его попросил. На практике он слал то, что уже лежало в кэше, и жёг трафик. Chrome выпилил поддержку в 106-й версии, nginx поддержку убрал, и если вам подрядчик в 2026 году предлагает настроить push, это маркер, что человек читал статью десятилетней давности. Вместо него давно используется <link rel="preload"> и заголовок 103 Early Hints.
Как проверить, что у вас сейчас
Три способа, от самого быстрого к самому подробному.
DevTools. Открываете сайт, F12, вкладка Network, правой кнопкой по шапке таблицы, включаете колонку Protocol. Обновляете страницу. В колонке будет http/1.1, h2 или h3. Смотреть надо не на один запрос, а на все: типичная картина, когда сама страница едет по h2, а виджет обратного звонка со стороннего домена тянется по http/1.1.
curl. Быстрее и честнее, потому что не зависит от кэша браузера.
# версия протокола в первой строке ответа
curl -sI https://example.ru/ | head -1
# HTTP/2 200
# явная проверка поддержки HTTP/3 (нужен curl, собранный с ngtcp2 или quiche)
curl -sI --http3 https://example.ru/ | head -1
# HTTP/3 200
# заголовок alt-svc: сервер сам рассказывает, что умеет h3
curl -sI https://example.ru/ | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
# что согласуется на уровне TLS ALPN
openssl s_client -alpn h2 -connect example.ru:443 </dev/null 2>/dev/null | grep -i alpn
# ALPN protocol: h2Если curl --http3 ругается на неизвестную опцию, дело не в сайте, а в вашей сборке curl. В Windows-сборке из состава системы HTTP/3 обычно нет, в свежих сборках от curl.se есть.
Онлайн-сервисы. Когда надо показать заказчику картинку, а не терминал. Подходят http3check.net, tools.keycdn.com/http2-test, вкладка Details в WebPageTest. Яндекс Вебмастер и PageSpeed Insights версию протокола не показывают вообще, поэтому спорить с сеошником их скриншотами бесполезно.
Отдельно проверьте админку и статику из разных подсетей. У меня был случай, когда фронт стоял за российским CDN с h3, а прямые обращения к origin шли по http/1.1, и заказчик честно видел h3, пока не отключил CDN на время переноса.
Как включить
Обязательное условие для обеих версий: HTTPS. Формально HTTP/2 умеет работать открытым текстом (режим h2c), но ни один браузер этого не поддерживает, так что без валидного сертификата разговора нет.
nginx. С версии 1.25.1 директива поменялась, и на этом спотыкаются регулярно. Раньше писали listen 443 ssl http2;, сейчас так делать не надо, конфиг ругнётся предупреждением. Правильно:
server {
listen 443 ssl;
listen 443 quic reuseport; # HTTP/3, требует nginx 1.25+ с --with-http_v3_module
listen [::]:443 ssl;
http2 on;
http3 on;
ssl_protocols TLSv1.2 TLSv1.3;
add_header Alt-Svc 'h3=":443"; ma=86400' always;
}После правки обязательно nginx -t, потом systemctl reload nginx. И проверьте, что UDP-порт 443 открыт в firewall: про TCP помнят все, про UDP забывают через раз, а без него h3 просто молча не поднимается и всё откатывается на h2.
Apache. Нужен модуль mod_http2 и строка Protocols h2 http/1.1 в конфиге виртуалхоста. Подводный камень в том, что HTTP/2 не работает с MPM prefork, а prefork обычно стоит из-за mod_php. То есть придётся переехать на php-fpm и MPM event. На собственном VPS это полчаса работы, на shared за вас это уже решил хостер. HTTP/3 в Apache официально не поддерживается до сих пор, только через фронтенд-прокси.
LiteSpeed и OpenLiteSpeed. Здесь всё из коробки, h2 и h3 включены по умолчанию, отдельно настраивать нечего. Про разницу между этими серверами и то, как понять, что у вас стоит, писал подробно в статье про LiteSpeed, nginx и Apache.
Shared-хостинг. Своего доступа к конфигу у вас нет, .htaccess протокол не переключает. Варианта два: тикет в поддержку с вопросом «включён ли HTTP/2 и HTTP/3 на моём тарифе» или CDN перед сайтом. Второй способ работает почти всегда, потому что современные CDN отдают клиенту h3, даже если origin у них отвечает по http/1.1. Российский CDN уровня Selectel или Yandex Cloud CDN обойдётся в районе 500-1500 рублей в месяц на трафике небольшого сайта.
Ориентир по рынку на середину 2026 года: HTTP/2 есть на всех сколько-нибудь живых российских хостингах, это давно гигиена. HTTP/3 на shared-тарифах пока лотерея, чаще встречается там, где под капотом LiteSpeed. Если хостинг в 2026 году всё ещё отдаёт http/1.1, это повод не тикет писать, а переезжать: значит, инфраструктуру не трогали лет пять.
Оптимизации, которые протухли
Вот это самая полезная часть статьи, потому что переключить протокол дело пятнадцати минут, а вычистить старые костыли из темы никто не догадывается годами.
| Приём | Зачем был нужен при HTTP/1.1 | Что с ним сейчас |
|---|---|---|
| Склейка всех CSS и JS в один файл | Обойти лимит в 6 соединений | Вредно: одна правка сбрасывает кэш всего бандла, блокирует рендер целиком |
| CSS-спрайты из иконок | Тот же лимит на картинки | Вредно: тянете 60 иконок ради трёх, плюс боль с ретиной |
| Домены-шарды (img1, img2, static) | Умножить лимит соединений | Вредно: каждый домен это лишние DNS, TCP и TLS рукопожатия |
| Инлайн картинок в base64 | Убрать лишний запрос | Спорно: файл раздувается на треть и не кэшируется отдельно |
| Отдельный cookie-less домен для статики | Куки летели с каждым запросом | Не нужно: HPACK сжимает заголовки |
| Отказ от модульного JS ради одного бандла | Меньше файлов любой ценой | Не нужно: ES-модули по h2 едут нормально |
Что осталось полезным и после перехода, чтобы не выплеснуть ребёнка:
- сжатие Brotli или gzip на текстовых ответах, это ортогонально версии протокола и даёт больше, чем сам протокол (подробности и настройка здесь),
- минификация CSS и JS, потому что мультиплексирование не уменьшает размер файла,
- заголовки кэширования и версионирование ассетов,
preconnectк сторонним доменам иpreloadдля критичных шрифтов,- lazy loading картинок ниже первого экрана,
- критический CSS инлайном в head.
Реальный пример из практики. Тема на WordPress, самописная, автор честно собрал 14 стилей в bundle.min.css на 780 КБ. Разбили на три файла (критика инлайном, основной, отложенный для секций ниже) и убрали спрайт на 240 КБ, заменив иконки на inline SVG по месту. Протокол не трогали вообще, он и так был h2. LCP упал с 3,9 до 2,4 секунды. То есть выигрыш дала не смена протокола, а отказ от оптимизаций под протокол, которого на сайте уже давно нет. Про то, из чего вообще складывается эта метрика и куда смотреть первым делом, писал в разборе LCP больше 2,5 секунд.
Где выигрыш есть, а где его нет
Заметно будет:
- на страницах с большим количеством мелких запросов, каталог с превьюшками, галерея, лента блога с картинками,
- на мобильном интернете с потерями пакетов, особенно у HTTP/3,
- на сайтах с тяжёлыми куками, когда HPACK срезает килобайты на каждом запросе,
- при географической удалённости, когда сокращение числа рукопожатий экономит реальные RTT.
Не поможет вообще:
- если тормозит сервер. Сайт на разжиревшей базе с шестью секундами до первого байта одинаково медленный на любой версии протокола. Это лечится в другом месте, см. разбор TTFB больше 600 мс,
- если у вас на главной одно фоновое видео на 12 мегабайт. Один жирный файл едет одинаково по любому протоколу,
- если рендер блокирует сторонний скрипт чата или пиксель рекламной системы. Мультиплексирование не ускоряет чужой сервер,
- если картинки не сжаты. JPEG на 4 МБ останется JPEG на 4 МБ.
Грубый ориентир, который я использую при оценке: если у сайта меньше 25-30 запросов на страницу, ждать от смены протокола чего-то заметного не стоит. Если больше 80, разница будет видна на графике.
Стоит ли гнаться за HTTP/3
Мой ответ: включить, если даётся бесплатно, и не менять из-за него хостинг.
Аргументы за: реально быстрее на плохих сетях, а мобильный трафик у большинства клиентов уже 60-75 процентов. Ноль стоимости, если хостер или CDN уже умеет. Браузеры поддерживают все, включая Safari с 16-й версии.
Аргументы против спешки: UDP-трафик на 443 порту режут в некоторых корпоративных сетях и у отдельных провайдеров, поэтому браузер всё равно должен уметь откатиться на h2, и эта логика фолбэка иногда добавляет задержку на первом соединении. На проводном офисном интернете разница между h2 и h3 в пределах погрешности измерения. И самое приземлённое: на shared-хостинге вы на это не влияете.
Отдельно про софт. Если сайт стоит за старым Apache без фронта, поддержки h3 не будет, и городить перед ним nginx только ради протокола экономически бессмысленно. Проще дождаться, пока хостер сам обновит стек, или уехать туда, где уже.
Как замерить до и после
Замер должен быть воспроизводимым, иначе получите классическое «вроде стало пошустрее». Методика простая.
# 10 прогонов, вывод по времени соединения и первого байта
for i in $(seq 1 10); do
curl -s -o /dev/null -w "%{http_version} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}n"
https://example.ru/catalog/
done
# принудительно старый протокол для сравнения на том же сервере
curl -s -o /dev/null --http1.1 -w "%{http_version} total=%{time_total}n" https://example.ru/catalog/curl меряет один запрос, а нам важна сборка страницы целиком. Поэтому дальше WebPageTest с профилем 4G и тремя прогонами, смотрим медиану, а не лучший результат. Chrome DevTools с троттлингом Fast 3G годится для быстрой прикидки, но цифры у него оптимистичнее реальности.
Живой пример. Магазин на WooCommerce, 640 товаров, страница категории тянет 96 запросов, из них 41 картинка. Хостинг переехал с nginx без h2 на LiteSpeed с h2 и h3, код сайта не менялся ни строкой. Медиана трёх прогонов, эмуляция 4G с задержкой 60 мс:
| Метрика | http/1.1 | h2 | h3 |
|---|---|---|---|
| TTFB | 480 мс | 470 мс | 440 мс |
| LCP | 4,1 с | 3,3 с | 3,1 с |
| Полная загрузка | 7,8 с | 5,9 с | 5,6 с |
| Объём заголовков | 71 КБ | 9 КБ | 8 КБ |
Основной скачок между http/1.1 и h2, дальше прирост скромный. TTFB почти не двигается, и это ожидаемо: он про то, как быстро думает сервер, а не про то, как пакеты летят по сети.
Чек-лист на полчаса
- Проверить протокол командой
curl -sIдля главной, страницы каталога и одного файла статики. - Проверить
alt-svcв ответе, чтобы понять, анонсирует ли сервер h3. - Если http/1.1, написать в поддержку хостинга. Ответ «у нас не поддерживается» считать поводом к переезду.
- Открыть DevTools и найти запросы, которые едут по старому протоколу со сторонних доменов. Часто это виджеты, которые давно пора выкинуть.
- Найти в теме склеенные бандлы, спрайты и домены-шарды. Разобрать.
- Убедиться, что Server Push нигде не настроен и
Link: rel=preloadне отправляется пачкой на 30 файлов. - Замерить WebPageTest на 4G до правок, сохранить ссылку на отчёт.
- После правок замерить снова тем же профилем, сравнить медианы.
Пункты 5 и 6 занимают больше времени, чем всё остальное вместе взятое, и дают основной результат.
Что делать дальше
Если после проверки выяснилось, что протокол давно новый, а сайт всё равно медленный, дело не в протоколе. Начинать надо с сервера и картинок, а не с переключателей в панели хостинга.
Если нужен человек, который посмотрит на конкретный сайт и скажет, где именно теряются секунды, напишите через форму на главной: за пару часов я обычно нахожу, что даёт основную задержку, и присылаю список работ с оценкой. Разбор старых оптимизаций и чистка темы это разовая проектная задача, регулярные замеры скорости и контроль после обновлений входят в абонентское обслуживание. Что именно туда входит и где проходит граница между абонементом и проектом, разбирал в рубрике про скорость.
Частые вопросы
Как проверить версию протокола
Открыть инструменты разработчика, вкладку с сетевыми запросами и посмотреть колонку с протоколом: h2 значит HTTP/2, h3 значит HTTP/3. Колонку иногда надо включить в настройках таблицы.
Что даёт HTTP/2 сайту
Параллельную загрузку многих файлов по одному соединению. Отсюда и следствие: дробить стили и скрипты на несколько файлов теперь не вредно, а склеивать всё в один монолит вредно.
Какие приёмы ускорения устарели
Склейка всех CSS в один файл, спрайты из иконок и раскидывание статики по нескольким поддоменам. Всё это придумывали против ограничений старого протокола, которых больше нет.
Стоит ли гнаться за HTTP/3
Специально переезжать ради него не стоит. Выигрыш заметен на нестабильной мобильной сети, а на проводном интернете разница в пределах погрешности. Если хостинг даёт его сам, включайте.
