HTTP/2 и HTTP/3: почему сайт с 80 файлами тормозит даже на быстром хостинге

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

Я занимаюсь SEO с 2005 года и застал все три поколения протокола в работе. Раньше половина рекомендаций по скорости сводилась к тому, чтобы «уменьшить количество запросов». Сегодня эта рекомендация в лучшем случае бесполезна, а в некоторых случаях делает сайт медленнее. Ниже — что изменилось, как понять, на каком протоколе работает ваш сайт прямо сейчас, что включить и почему после включения вы можете не увидеть никакого ускорения. Если разбираться самому некогда, можно просто заказать SEO-продвижение сайта и передать техническую часть мне.

Почему сайт с 80 файлами тормозит даже на быстром хостинге

Откройте любую внутреннюю страницу типового корпоративного сайта на WordPress и посчитайте, из чего она собрана. Обычная картина: один HTML-документ, 12–20 файлов CSS (тема, дочерняя тема, каждый плагин со своим стилем), 20–30 файлов JavaScript (jQuery, слайдер, формы, аналитика, чат, карта), 4–8 шрифтовых файлов, набор иконок, логотип, фавиконки, десяток картинок в контенте. Восемьдесят запросов — это не рекорд, это средний сайт с шестью установленными плагинами.

Дальше начинается арифметика, которую не видно в панели хостинга. Каждый файл — это отдельный запрос. Браузер не может отправить их все сразу: он открывает несколько соединений к домену и через каждое просит по одному файлу за раз. Пока файл не пришёл, соединение занято. Отсюда и очередь.

Важно понимать, из чего складывается время одного запроса. Оно почти не зависит от размера файла, если файл маленький. Основное — это задержка сети: сигнал должен дойти до сервера и вернуться. Между Москвой и московским дата-центром это единицы миллисекунд, между Москвой и европейским сервером — 40–60 мс, между мобильным телефоном в области и тем же сервером — легко 80–150 мс. Умножьте задержку на количество «раундов», и вы получите те самые секунды, которые не объясняются ни процессором, ни диском.

Именно поэтому диагноз «медленный хостинг» ставят слишком часто. Медленный хостинг — это когда долго формируется сам HTML-документ, и это отдельная история про время до первого байта. А когда HTML пришёл быстро, но страница дорисовывается ещё три секунды — узкое место в том, как браузер забирает остальные восемьдесят файлов.

Что тормозит	Как выглядит в отчётах	Лечится протоколом?
Долго формируется HTML на сервере	Большой TTFB, первая строка в Network висит 1–3 с	Нет
Много мелких файлов в очереди	TTFB нормальный, но «водопад» запросов ступеньками	Да, заметно
Тяжёлые несжатые картинки	Один-два запроса по 1–3 МБ	Нет
Блокирующий JavaScript в head	Отрисовка стоит, пока скрипт не выполнится	Нет
Смена сети на мобильном	Загрузка «замерзает» на несколько секунд	Да, HTTP/3

Мультиплексирование: что HTTP/2 меняет в очереди

В HTTP/1.1 действует правило «одно соединение — один запрос за раз». Браузер обходит ограничение единственным доступным способом: открывает к домену несколько соединений параллельно. Обычно шесть. Шесть каналов на восемьдесят файлов — это тринадцать заходов подряд, и каждый заход стоит одной сетевой задержки.

Есть ещё неприятная деталь: если первый файл в очереди отдаётся медленно, все следующие в этом же соединении ждут. Это называют блокировкой начала очереди. Достаточно одного подвисшего скрипта стороннего сервиса, чтобы за ним встали пять безобидных иконок.

HTTP/2 убирает и то, и другое. Соединение с сервером устанавливается одно, но внутри него открывается сколько угодно логических потоков. Файлы режутся на кадры, кадры разных файлов идут вперемешку в обе стороны одновременно, а браузер собирает их обратно. Это и есть мультиплексирование. Восемьдесят файлов запрашиваются практически одномоментно, и очередь как явление исчезает.

Что ещё даёт HTTP/2 из полезного на практике:

• Сжатие заголовков. К каждому запросу браузер прикладывает служебные данные: user-agent, куки, referer. На восьмидесяти запросах это набегает в сотни килобайт повторяющегося текста. HTTP/2 сжимает заголовки и не пересылает то, что уже отправлял.
• Приоритеты. Браузер может сказать серверу, что CSS первого экрана важнее, чем картинка в подвале, и получить его раньше.
• Одно соединение вместо шести. Меньше рукопожатий TLS, меньше нагрузки на сервер при большом трафике.

Почему HTTP/2 на практике требует HTTPS

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

Практический вывод простой: нет сертификата — нет HTTP/2. Сначала сайт переводится на HTTPS, и делается это одним каноническим адресом, без цепочек вида «http → www → https → https без www». Каждая лишняя ступенька — это дополнительный полный круг до сервера ещё до того, как началась загрузка. Как это проверять, я подробно разбирал в материале про цепочки и петли редиректов.

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

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

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

Второе отличие важно именно для мобильной аудитории. TCP-соединение привязано к паре «IP-адрес и порт». Человек вышел из офиса, телефон переключился с Wi-Fi на мобильную сеть, IP сменился — соединение умерло, всё устанавливается заново, включая шифрование. QUIC вместо адреса использует идентификатор соединения, поэтому переезд между сетями он переживает без разрыва: загрузка просто продолжается. Плюс рукопожатие в QUIC совмещено с установкой шифрования, а при повторном заходе на сайт может обойтись вообще без лишнего круга.

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

HTTP/1.1, HTTP/2 и HTTP/3: таблица сравнения

Параметр	HTTP/1.1	HTTP/2	HTTP/3
Как передаются файлы	По одному в каждом соединении, строго по очереди	Все параллельно в одном соединении, кадрами вперемешку	Так же параллельно, но потоки независимы физически
Сколько соединений к домену	Обычно 6	1	1
Транспорт	TCP	TCP	QUIC поверх UDP
Потеря пакета	Тормозит одно соединение из шести	Тормозит все потоки сразу	Тормозит только свой поток
Смена сети (Wi-Fi → LTE)	Разрыв, всё заново	Разрыв, всё заново	Соединение сохраняется
Служебные заголовки	Текстом, полностью в каждом запросе	Сжимаются, повторы не пересылаются	Сжимаются
Шифрование	Необязательно	Формально необязательно, на практике только HTTPS	Встроено в протокол, без вариантов
Где выигрыш заметнее всего	—	Много мелких файлов, дальний сервер	Мобильные сети, потери пакетов, роуминг
Поддержка браузерами	Полная	Все актуальные с 2015 года	Chrome, Edge, Firefox, Safari, мобильные — да; старые версии откатываются на HTTP/2

Отдельно проговорю то, что часто пугает: включение нового протокола не ломает совместимость. Клиент и сервер договариваются при подключении. Если браузер посетителя не умеет HTTP/3, он молча работает по HTTP/2. Если не умеет и его — по HTTP/1.1. Поисковые роботы тоже нормально ходят по любому из вариантов, так что риска «Яндекс перестанет видеть сайт» здесь нет.

Приёмы из эпохи HTTP/1.1, которые теперь мешают

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

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

Спрайты из иконок. Классика: тридцать иконок склеивают в одну картинку и вырезают кусочки через CSS. На HTTP/2 экономия на запросах близка к нулю, а расплата вполне реальная — грузится вся простыня целиком, даже если на странице видны две иконки; менять одну иконку означает пересобирать и перевыкачивать спрайт; ретина-версии удваивают вес. Сегодня иконки правильнее держать как отдельные SVG или встроить в разметку.

Раздача статики с доменов-шардов. Приём назывался «шардинг»: картинки уезжали на static1.site.ru и static2.site.ru, чтобы к каждому домену браузер открыл свои шесть соединений. На HTTP/2 это прямой вред. Каждый лишний домен — это отдельный поиск в DNS, отдельное TCP-соединение, отдельное рукопожатие TLS. Вместо одного эффективного канала вы принудительно делаете три дорогих. Приоритеты между доменами тоже не работают: сервер не знает, что важнее, если файлы на разных хостах.

Встраивание картинок прямо в CSS через base64. Раньше это убирало запрос. Теперь это раздувает файл стилей, который блокирует отрисовку, и лишает картинку собственного кэша. Про то, как правильно работать с изображениями, есть подробный разбор про WebP, размеры и отложенную загрузку.

Приём	Зачем делали на HTTP/1.1	Что происходит на HTTP/2 и HTTP/3	Что делать сейчас
Один общий бандл JS	Убрать запросы из очереди	Лишний код на каждой странице, кэш слетает целиком	Делить по страницам, оставлять несколько файлов
Спрайты иконок	30 запросов вместо 1	Грузится всё ради двух иконок	Отдельные SVG или встроенные в HTML
Домены-шарды для статики	Больше параллельных соединений	Лишние DNS, TCP и TLS на каждый домен	Отдавать всё с одного домена
base64 в CSS	Минус один запрос	Раздутый блокирующий CSS, нет кэша картинки	Обычные файлы изображений
Минификация и gzip/brotli	Меньше вес	Работает так же хорошо	Оставить, это по-прежнему полезно
Кэш-заголовки на статику	Не качать повторно	Работает так же хорошо	Оставить, срок от месяца

Правило, которое я формулирую заказчикам одной фразой: на HTTP/2 борются не с количеством файлов, а с количеством лишних байтов и с блокировкой отрисовки. Это разные задачи, и старые плагины «оптимизации» решают вчерашнюю.

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

Проверка занимает минуту и не требует доступа к серверу.

Вкладка Network в браузере. Откройте сайт, нажмите F12, перейдите на вкладку Network и перезагрузите страницу. По умолчанию колонки Protocol не видно — щёлкните правой кнопкой по шапке таблицы и включите её. Значения читаются так: http/1.1 — старый протокол; h2 — HTTP/2; h3 — HTTP/3. Смотрите не только на главный документ, но и на строки со скриптами, шрифтами и картинками: бывает, что сама страница отдаётся по h2, а виджет стороннего сервиса тянет свои файлы по http/1.1 — это уже не ваша зона ответственности.

curl из терминала. Команда curl -I --http2 https://ваш-сайт.ru/ в ответе покажет первой строкой HTTP/2 200, если протокол включён. Для HTTP/3: curl -I --http3 https://ваш-сайт.ru/ — работает, если ваша сборка curl собрана с поддержкой QUIC, иначе команда честно скажет, что не умеет.

Заголовок alt-svc. Даже если соединение установилось по HTTP/2, сервер обычно сообщает о поддержке третьей версии заголовком вида alt-svc: h3=":443"; ma=86400. Его видно и в curl, и во вкладке Headers. Это значит: «в следующий раз можешь прийти по HTTP/3». Отсюда типичная путаница — при первом заходе браузер показывает h2, а при повторном h3.

Онлайн-проверки. Подойдёт любой сервис проверки HTTP/2 и HTTP/3, а также отчёт SSL Labs — он заодно покажет качество сертификата и версию TLS. Смысл онлайн-проверки в том, что она смотрит на сайт снаружи, а не из вашего браузера с его расширениями и корпоративным прокси.

Способ	Что делаете	Что означает результат
DevTools → Network → Protocol	F12, перезагрузка, включить колонку	http/1.1, h2 или h3 по каждому файлу отдельно
curl -I —http2	Одна команда в терминале	Строка HTTP/2 200 = включено
Заголовок alt-svc	Смотреть ответ сервера	Есть h3 — HTTP/3 доступен, браузер перейдёт на него
Онлайн-чекеры и SSL Labs	Ввести домен	Взгляд снаружи, заодно проверка сертификата
Отчёт PageSpeed / Вебмастер	Прогнать страницу	Косвенно: длинные «водопады» мелких файлов

Как включить HTTP/2 и HTTP/3

Начну с главного: в девяти случаях из десяти включать вручную ничего не надо, всё уже включено на стороне хостера. Проверять всё равно стоит, потому что оставшийся десятый случай встречается регулярно на старых серверах и у мелких провайдеров.

Панель хостинга. В ISPmanager, cPanel, FastPanel и панелях крупных российских хостеров это обычно галочка в настройках домена или сайта, рядом с выбором версии PHP и включением SSL. Формулировки разные: «HTTP/2», «Включить HTTP/2 для домена», иногда прячется в разделе настроек nginx. Обязательное условие — уже выпущенный и работающий сертификат.

nginx. В конфигурации сайта в директиве прослушивания добавляется соответствующий параметр: listen 443 ssl http2; для второй версии. В свежих версиях nginx синтаксис изменился: протокол включается отдельной строкой http2 on; внутри блока сервера. Для HTTP/3 дополнительно нужен UDP-слушатель listen 443 quic reuseport;, заголовок alt-svc в ответе и открытый порт 443 по UDP в файрволе. Про последний забывают чаще всего: TCP открыт, UDP закрыт, и HTTP/3 «включён», но не работает ни у кого.

Apache. Нужен модуль mod_http2, после чего в конфигурации указывается Protocols h2 h2c http/1.1. Важная тонкость: HTTP/2 в Apache не работает в связке с режимом обработки prefork, который до сих пор стоит по умолчанию на многих серверах вместе с mod_php. Приходится переводить сайт на PHP-FPM. Если у вас перед Apache стоит nginx как фронтенд — а это самая частая схема на панелях, — протокол включается именно в nginx, и на Apache трогать ничего не нужно.

Общий хостинг, где галочки нет. Сценарий такой. Сначала пишете в поддержку прямым вопросом: «Поддерживает ли сервер HTTP/2 и HTTP/3 для моего домена, и как включить». Часто выясняется, что поддержка есть, просто не вынесена в интерфейс. Если ответ отрицательный — есть два пути. Первый: поставить сайт за CDN или прокси-сервис, который сам терминирует соединение с посетителем; тогда до посетителя трафик идёт по HTTP/2 или HTTP/3, даже если ваш сервер отвечает по HTTP/1.1. Второй: сменить площадку. Отсутствие HTTP/2 в 2026 году — это маркер того, что сервер не обновляли годами, а значит, там же будет старый PHP и старый OpenSSL. О том, чем тарифы отличаются по сути и что за ними стоит, я писал в разборе видов хостинга.

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

Когда выигрыша не будет

Здесь я обязан быть честным, потому что завышенные ожидания от «включим HTTP/3 и полетит» приводят к разочарованию и к тому, что реальные проблемы остаются нетронутыми. Протокол — это способ доставки. Он не меняет ни то, что вы доставляете, ни то, как быстро это готовится.

• Узкое место в TTFB. Если сервер думает над HTML две секунды, вы сэкономите на очереди файлов условные 300 мс и не заметите разницы. Сначала PHP, база, кэш — потом протокол.
• Тяжёлые картинки. Фотография на 2 МБ будет качаться одинаково по любому протоколу. Мультиплексирование ускоряет много мелких файлов, а не один большой.
• Блокирующий JavaScript. Если скрипт в head останавливает отрисовку, посетитель смотрит на белый экран независимо от версии HTTP. Как это влияет на индексацию, разобрано в статье про сайт на JavaScript, который робот видит пустым.
• Мало файлов. Лендинг из десяти запросов на HTTP/1.1 и так укладывался в два обхода очереди. Выигрыш будет, но в пределах десятков миллисекунд.
• Сторонние виджеты. Чат, карта, пиксели рекламных систем грузятся со своих доменов и по своим протоколам. Ваш HTTP/3 на них не распространяется.
• Быстрый проводной интернет и близкий сервер. При задержке в 3–5 мс очередь из шести соединений почти не мешает, эффект будет минимальным. HTTP/2 и особенно HTTP/3 выстреливают там, где связь плохая: мобильный интернет, регионы, дальние сервера.
• Конструкторы сайтов. На Tilda, Wix и подобных протокол вам вообще неподконтролен, платформа решает сама. Там узкое место обычно в другом: в объёме генерируемого платформой кода и в сторонних скриптах.

И ещё одно, о чём спрашивают почти всегда: включение HTTP/2 не является фактором ранжирования. Поиск не начисляет баллы за версию протокола. Он смотрит на то, что видит посетитель: время отрисовки, стабильность вёрстки, отзывчивость. Протокол влияет на эти метрики косвенно, и в этом качестве действительно попадает в Core Web Vitals. Но ждать роста позиций от одной галочки не стоит — связь скорости с выдачей устроена сложнее, я разбирал её в материале медленный сайт и низкие позиции.

Порядок работ: с чего начинать, если сайт медленный

Правильная последовательность экономит недели. Она такая.

1. Замерить TTFB. Если больше 500 мс — заниматься сервером, кэшем и базой, остальное пока отложить.
2. Проверить протокол в Network. Если http/1.1 — включить HTTP/2, это самое дешёвое улучшение из всех.
3. Посмотреть на «водопад» запросов: сколько файлов, какие блокируют отрисовку, что грузится до первого экрана.
4. Убрать наследие HTTP/1.1: разбить бандлы по страницам, отказаться от шардов, вынести иконки из спрайта.
5. Заняться картинками: современные форматы, правильные размеры, отложенная загрузка ниже первого экрана.
6. Разгрузить JavaScript: отложенное выполнение, удаление того, что не используется на конкретной странице.
7. Включить HTTP/3, если хостер умеет, и убедиться, что UDP-порт открыт.
8. Перемерить и сравнить с исходной точкой, а не с ощущениями.

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

Коротко

• Восемьдесят файлов на странице — это не редкость, а норма для сайта с плагинами. На HTTP/1.1 браузер тянет их по шесть штук за раз, и время уходит на ожидание, а не на скачивание.
• HTTP/2 открывает одно соединение и качает всё параллельно внутри него. Очередь исчезает, заголовки сжимаются.
• HTTP/3 работает поверх QUIC на UDP: потерянный пакет тормозит только свой файл, а смена Wi-Fi на мобильную сеть не рвёт соединение. Основной выигрыш — на телефонах и плохой связи.
• HTTP/2 без HTTPS в браузерах не работает. Сертификат — обязательное условие.
• Старые приёмы — общий бандл, спрайты, домены-шарды, base64 в CSS — на новых протоколах бесполезны или вредны. Минификация, сжатие и кэш-заголовки по-прежнему нужны.
• Проверка — колонка Protocol во вкладке Network: http/1.1, h2 или h3. Плюс curl и заголовок alt-svc.
• Включается чаще всего галочкой в панели хостинга. В nginx и Apache — парой строк в конфигурации, для HTTP/3 нужен открытый UDP-порт.
• Протокол не лечит большой TTFB, тяжёлые картинки и блокирующий JavaScript. И не является фактором ранжирования сам по себе.

Чеклист: что сделать с протоколом на своём сайте

Шаг	Как проверить	Норма
Сайт работает по HTTPS	Адресная строка, срок сертификата	Действующий сертификат, автопродление настроено
Нет цепочек редиректов на входе	curl -IL по http-версии домена	Максимум один переход до финального адреса
Протокол главной страницы	DevTools → Network → Protocol	h2 или h3
Протокол статики	Те же строки CSS, JS, шрифтов	Тот же h2/h3, не http/1.1
Поддержка HTTP/3 анонсируется	Заголовок alt-svc в ответе сервера	Присутствует h3=»:443″
UDP-порт 443 открыт	Настройки файрвола на сервере	Открыт, иначе HTTP/3 не заработает
Вся статика на одном домене	Список хостов в Network	Нет шардов вида static1, static2
Нет спрайтов и base64-простыней	Поиск по CSS темы	Иконки отдельными файлами
JS разбит по страницам	Размер бандла на простой странице	Нет мегабайтного файла на контактах
Сжатие включено	Заголовок content-encoding	gzip или br
Кэш-заголовки на статику	Заголовок cache-control	От месяца, с версионированием файлов
TTFB измерен	Первая строка в Network	До 500 мс, лучше до 200 мс
Кэш сброшен после изменений	Серверный кэш и плагин	Проверять без параметров в URL
Замер повторён после правок	Тот же инструмент, та же страница	Есть цифра «до» и цифра «после»

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