HTTP/2: что это и зачем он вам

Ваш сайт наверняка давно переехал на безопасный протокол HTTPS, необходимость которого уже несколько лет как анонсировали представители поисковых систем. Но используете ли вы HTTP/2? Что это и почему вам давно пора перейти на этот протокол передачи данных – в этой статье.

Меня спросят: «Эй, а ты зачем в 2022 году вообще пишешь про HTTP/2, когда на подходе HTTP/3?» – и я скажу вот что. Я регулярно провожу аудиты сайтов, в том числе – в рамках конкурентного анализа. В аудит входит и проверка используемого протокола передачи данных. И увы, вижу, что примерно половина сайтов работает на уже устаревшем протоколе данных, а многие полезные фичи HTTP/2 используются разве что теми, кто использует выделенные сервера.

Личное же общение со многими вебмастерами показывает, что они либо вообще не знают об имеющихся возможностях, либо что-то такое слышали, но без подробностей. А тема – достаточно важная, чтобы потратить пять-десять минут на ликбез. К нему и перейдём.

Рассмотрим стандартную схему передачи данных по старому-доброму протоколу HTTP/1. Вы обращаетесь к какому-то сайту в интернете – и начинается кипучая, но скрытая от глаз пользователя деятельность.

Каждая фаза процесса загрузки неравнозначна по времени и важности для посетителя. Статистика утверждает, что большинство пользователей не желает ждать более 4 секунд, а не дождавшись – закрывает вкладку и идёт на другой сайт. И каждая секунда загрузки серьёзно снижает показатели конверсии. Резонно: люди не любят ждать, и люди начинают сомневаться в покупке, если им кажется, что сайт подвисает.

Изначально HTTP был простым текстовым протоколом и предназначался только для передачи гипертекстовых документов. Отправил GET-запрос, получил в ответ HTML, ничего лишнего. По мере развития протокола и интернета вообще по этому протоколу стали передаваться и другие типы файлов.

В версии HTTP/1.0 после получения ответа соединение закрывалось, и чтобы отправить другую команду HTTP, соединение нужно было открывать заново. В версии HTTP/1.1 соединение уже оставалось открытым по умолчанию.

Синтаксис HTTP первых версий был прост и представлял собой текстовый формат запроса-ответа. Начиная с версии HTTP/1.0 появились заголовки, благодаря чему можно было отправлять GET-запросы с условиями. Если страница не была изменена, можно было не загружать новую копию ресурса.

С появлением метода HEAD клиент мог загружать все метаданные, не загружая сам ресурс. Благодаря этому поисковые системы смогли проверять, обновлялся ли URL, и загружать только обновленные данные.

Вместе с появлением метода POST клиент мог отправлять данные непосредственно на сервер, если сервер позволял принимать данные. Благодаря этому стала возможна работа веб-форм, загрузка пользовательских файлов и т.п.

Большим ограничением протокола стала количество одновременно отправляемых запросов, в среднем – 5-8, тогда как среднестатистический сайт уже 10 лет назад редко ограничивался 50-70.

Возможностей протокола было достаточно, чтобы читать, просматривать картинки, оставлять комментарии. Но для передачи чувствительной конфиденциальной информации протокол явно не годился, и ему на смену пришёл защищенный HTTPS.

Протокол HTTP передает сообщения в незашифрованном виде. Интернет – сеть из компьютеров, а не прямая связь между двумя компьютерами. Отправленное сообщение проходит длинный путь, отследить который вы не можете – и есть риск, что злоумышленники перехватят ваш текст, прочитают его и даже изменят по дороге.

Протокол HTTPS шифрует передаваемые сообщения с помощью протокола TLS или уже устаревшего SSL. Благодаря HTTPS протокол HTTP получил три важных свойства:

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

Но самое важное в контексте этой статьи: протокол HTTPS подразумевает дополнительные запросы и «рукопожатия», ещё более осложняя процесс отправки запросов и загрузки данных.

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

В результате развития протокола HTTP стало возможным передавать не только текстовое содержимое, но и мультимедийные файлы, сохранять соединение открытым и отправлять несколько запросов одновременно. Современный сайт загружает около 2,3 МБ данных при отправляемых 70 запросов в целом (фактически, число запросов может доходить до 150 на плохо оптимизированном шаблоне). С учётом того, что современный интернет в большей мере – мобильный, загрузка такого сайта становится слишком долгой.

Проблему можно охарактеризовать несколькими основными моментами:

Образно говоря: вы заходите в фаст-фуд быстренько перекусить, а вам начинают по очереди приносить салат, первое, второе, десерт. Не доели предыдущее блюдо – следующее не приносят. А вы даже не знаете, что там в меню, и сколько блюд вообще ожидается, и каковы будут порции.

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

Основными решениями долгие годы были следующие способы оптимизации быстродействия:

и т.п.

Сокращение количества запросов объединяло множество методов. Критически важные CSS и JS встраивались непосредственно в HTML. Изображения группировались с помощью спрайтинга. Из файлов текстового формата удалялось форматирование, комментарии, табуляция. Основными недостатками этого метода стали проблемы с кэшированием и избыточный расход трафика.

Создание параллельных HTTP-соединений было самым простым. Однако и тут есть ограничение в 4-8 соединений на домен. Чтобы обойти это ограничение, статические ресурсы размещают на CDN (файловом сервере) или на вспомогательном домене, открывающем дополнительные соединения. Благодаря тому, что речь идёт о другом домене (субдомене), браузер видит несколько разных серверов и может обращаться к ним одновременно.

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

Вопросы быстродействия – не единственный недостаток HTTP, и исправлять эти недостатки оказалось разумнее с помощью полного обновления протокола передачи данных. Таким протоколом и стал HTTP/2.

В 2014 году спецификация HTTP/2 была утверждена как стандарт, а с 2015 года получила поддержку во всех основных браузерах. Новые возможности включали:

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

Главное отличие этого протокола – использование двоичных данных вместо текстовых. Компьютерам сложнее работать с текстами, чем с двоичным протоколом. Кроме того, современный интернет уже сложно представить в исключительно текстовом формате.

Двоичный формат позволяет разделять HTTP-данные и отправлять их в отдельных фреймах, по частям. Полное сообщение складывается из всех полученных фреймов.

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

Каждый фрейм содержит метку потока, к которому принадлежит. Таким образом можно отправить сотню сообщений разом в одном мультиплексе, и ограничение в 6 сообщений снимается. А это значит, что дополнительные доменные соединения не нужны.

Браузеру уже не нужно составлять очередь из запросов, поскольку все или почти все запросы можно отправить разом (лимит в среднем составляет сотню запросов). Единственный негативный момент: это может привести к снижению пропускной способности, особенно если вы используете неоптимизированные изображения.

Важно определить приоритеты потоков, чтобы в первую очередь сервер отправлял важнейшие ресурсы. Это делается на уровне сервера. С помощью push-загрузки сервер может сразу отправить важные CSS и JS, и браузер может отобразить страницу быстрее, поскольку всё важное уже попало в браузерный кэш.

Очевидно, что все преимущества протокола передачи данных HTTP/2 для поисковой оптимизации связаны преимущественно с техническими вопросами. Лично я не считаю, что быстродействие сайта относится к важнейшим факторам ранжирования, однако игнорировать его нельзя. Медленный сайт, как минимум, не нравится посетителям и плохо сказывается на конверсиях – а это уже серьёзно.

Рассмотрим, что именно может стать лучше при переходе на HTTP/2.

Да, возможность использования HTTP/2 не относится к факторам ранжирования и не обещает улучшения позиций. Но его подключение сэкономит вам усилия на оптимизацию быстродействия, улучшит сканирование сайта, а ваши посетители будут иметь меньше проблем при взаимодействии с сайтом. Стоит ли овчинка выделки? – Ответ очевиден.

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

Возможности HTTP/2 не помогут сайтам, размещенным на слабых серверах, и при этом использующим "тяжёлый" код, избыток Javascript, изображения в высоком разрешении, встроенное в iframe видео. Типовые проблемы шаблона сайта я описал в отдельной статье. Как минимум, переход на HTTP/2 будет полезен, но понадобятся дополнительные настройки, что не всегда возможно, если вы используете виртуальный хостинг, а не выделенный сервер.

Единого способа нет, реализация в каждом конкретном случае зависит от сервера или хостинг-провайдера. В некоторых случая всё предельно просто. Например, на Timeweb вопрос решается единственной кнопкой. Возможности, правда, тоже очень ограничены.

Протокол поддерживают и nginx актуальных версий (по умолчанию), и Apache (через модуль mod_spdy). Если ваш сервер не поддерживает HTTP/2, можно подключить обратный прокси-сервер с поддержкой протокола. В любом случае, эту задачу должен решать ваш системный администратор, потому что единого рецепта для всех не существует.

Имейте в виду, что подключить HTTP/2 без сертификата SSL не получится: браузеры требуют использования этого протокола только в такой связке, и это логично.

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

Чтобы узнать, доступен ли ваш сайт по протоколу HTTP/2, воспользуйтесь одним из следующих способов.

Воспользуйтесь одним из онлайн-сервисов. Их много. Начните с https://http2.pro/

Посмотрите на результаты аудита странички в Lighthouse (Chrome). Если HTTP/2 недоступен, вы увидите соответствующую рекомендацию.

Воспользуйтесь инструментами разработчика в консоли Chrome. В списке ресурсов в колонке "Протокол" они будут помечены как "h2". (Колонка «Протокол» по умолчанию не отображается. Кликните правой кнопкой по заголовку таблички и поставьте галочку в соответствующей строке).

Переход на использование HTTP/2 – не фактор ранжирования сам по себе, и позиции по запросам не улучшит. Но более быстрые сайты и лучшая производительность упрощают работу с поведенческими метриками и оптимизируют процессы сканирования сайта поисковыми роботами. А это уже напрямую влияет на продвижение в поиске.

И не забывайте: веб-технологии не стоят на месте, и уже скоро стандартом станет новый протокол, известный сейчас как QUIC – его чаще всего и называют HTTP/3. Поддержка QUIC в современных браузерах уже есть, но я ни разу не слышал, чтобы виртуальный хостинг в РФ уже предлагал клиентам этот протокол. Кроме того, при нынешней моде на блокировки всего подряд HTTP/3 также попадает под раздачу – но это тема для совершенно других материалов.