Введение в HTTP/2 и скорость страницы

Опубликовано: 2020-01-03

Введение

В 1991 году была представлена ​​первая задокументированная версия протокола HTTP «запрос-ответ» (HTTP 0.9). С тех пор Интернет значительно расширился, и 24 года спустя в 2015 году была выпущена самая последняя версия протокола передачи гипертекста (HTTP/2), которая при правильном внедрении дает множество возможных преимуществ для производительности сайта.

Эта статья предназначена для SEO-специалистов, желающих внедрить HTTP/2 в рамках своих инициатив по оптимизации скорости страницы.

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

  1. Как это напрямую повлияет на поисковую оптимизацию и/или скорость страницы?
  2. Можно ли сделать рекомендацию на основе инсайта?
  3. Реально ли выполнить рекомендацию?

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

Из-за широкого характера темы существует большой объем знаний о HTTP/2, которые не нужны при попытке понять важность для SEO. Основным преимуществом HTTP/2 для SEO является скорость страницы.

Чтобы помочь вам ориентироваться в огромном количестве онлайновой информации, вот введение в HTTP/2, описывающее эволюцию от HTTP 1.1 до HTTP-совместимого Spdy от Google и, в конечном итоге, до HTTP/2.

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

Как Google оценивает скорость страницы?

Чтобы узнать, как Google оценивает Page Speed, посмотрите отчеты Chrome User Experience Reports . Эти отчеты предоставляют метрики взаимодействия с пользователем, показывающие, как пользователи взаимодействуют с популярными направлениями в Интернете. Это основано на ключевых показателях взаимодействия с пользователем (первая отрисовка, первая содержательная отрисовка, первая значимая отрисовка, время до взаимодействия) и дополнительно поддерживается с помощью общих инструментов, таких как Page Speed ​​Insights, Public Google Big Query Project, Lighthouse и Web Page Test. Использование этих показателей и инструментов может помочь добиться возможных улучшений в Page Speed.

Введение в HTTP/2

HTTP 1.1

К 2015 году HTTP 1.1 устарел. Прошли те времена, когда веб-страницы/сайты создавались/полагались на базовые HTML, CSS и JavaScript, а также на многочисленные ресурсы и различные фреймворки. Эпоха до 2015 года была основана на идее, что вы были ограничены одним запросом на TCP-соединение. Это приводило к ситуациям, когда веб-клиенты имели несколько ресурсов в очереди на загрузку, вызывая перегрузку сети и медленную загрузку страниц.

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

  • Простота
  • Высокая производительность
  • Надежность

Преимущества SEO для HTTP/2

Скорость страницы, вероятно, является основной причиной, по которой SEO-специалисты рассматривают возможность внедрения HTTP/2 как на своих собственных веб-сайтах, так и на веб-сайтах своих клиентов. Page Speed/Performance — это набор показателей, которые с 2010 года являются фактором ранжирования для запросов Desktop. В связи с ростом использования мобильных устройств в июле 2018 года Google официально объявил , что Page Speed ​​станет фактором ранжирования для мобильных устройств.

HTTP/2 предоставляет 3 основные функции, которые можно использовать при оптимизации сайтов для Page Speed:

  1. Мультиплексирование
  2. Сервер Push
  3. Приоритизация потоков

Мультиплексирование

Мультиплексирование позволяет веб-клиенту включать несколько запросов в одно TCP-соединение, что снижает нагрузку на сервер и уменьшает перегрузку сети.

Современные веб-клиенты (Chrome, Firefox, Safari и Opera), использующие более старые протоколы HTTP 1/1.1, по умолчанию имеют ограничение на количество одновременных TCP-соединений на одно имя хоста. Поэтому веб-клиент, использующий HTTP 1/1.1, может легко столкнуться с перегрузкой TCP. В современных веб-клиентах эта проблема решается с помощью мультиплексирования, которое может дать одно из наиболее значительных улучшений скорости страницы.

Ниже показано преимущество мультиплексирования с использованием сравнения HTTP/1.1 и HTTP/2, демонстрирующее типичное поведение, когда мультиплексирование HTTP/2 включено и отключено.

( WebpageTest, HTTP/1.1, мультиплексирование не продемонстрировано )

( WebpageTest, HTTP/2, продемонстрировано мультиплексирование )

На изображениях выше водопад на основе производительности используется для демонстрации загрузки ресурсов между пользователем (который запрашивает ресурсы) и сервером (кто какие ресурсы отвечает) веб-страницы. Как правило, ресурсы страницы включают HTML, JavaScript, CSS и изображения. Водопад на основе производительности демонстрирует точную точку вызова, загрузки и отображения определенного ресурса в клиенте, что имеет решающее значение для обнаружения, оценки и анализа проблем со скоростью страницы на сайте. Как показано на изображении выше «HTTP/2», все ресурсы начинают загружаться одновременно, и никакие ресурсы не начинают загружаться в другой момент. Поскольку HTTP/2 использует мультиплексирование и больше не полагается на отправку только одного запроса по одному TCP-соединению, несколько ресурсов могут быть загружены одновременно, как показано выше. Напротив, как показано на изображении «HTTP/1.1», ресурсы не загружаются одновременно, поскольку они не могут использовать функцию мультиплексирования. Средний современный браузер с HTTP/1.1 может одновременно иметь 6 подключений, но преимущество реализации HTTP/2 заключается в том, что рукопожатие TCP не требуется для каждого запроса, в то время как независимо от того, сколько подключений может выполняться одновременно с HTTP/1.1, начальный процесс подключения должен быть завершен каждый раз. Поэтому они начинают загружаться в разных точках, что приводит к более длительной загрузке страницы для пользователя.

( Диаграмма Upwork HTTP/1.1 и HTTP/2 )

Поисковые роботы, такие как Google и Bing, не получают прямой выгоды от реализации HTTP/2. Как описано выше, основная польза от этих оптимизаций потенциально может быть связана с Page Speed. Поэтому, хотя реализация HTTP/2 может не влиять напрямую на поисковый робот, она может повлиять на скорость страницы, которая является прямым фактором ранжирования для запросов Google для настольных компьютеров с 2010 г. и запросов для мобильных устройств с июля 2018 г. В результате очень важно, чтобы веб-сайты не доставляли медленный опыт для пользователей, поскольку Google может снижать производительность, влияя на рейтинг, или, в последнее время, сообщая пользователям, что ваш сайт может быть медленным.

Сервер Push

Server Push позволяет определенному серверу или пограничной сети отправлять ресурсы веб-клиентам, когда они не были запрошены клиентом. Чтобы понять, как работает push-уведомление сервера, в первую очередь важно понять шаблон запроса-ответа, которому следует веб-сайт. Пользователь запрашивает страницу с веб-сайта, и сервер отвечает запрошенным контентом/ресурсом.

Гипотетически представьте себе сайт, все стили которого определены во внешней таблице стилей с именем styles.css. Когда пользователь запрашивает HTML-скелет для страницы (скажем, в данном случае index.html), сервер push может «протолкнуть» CSS пользователю сразу после начала отправки ответа на index.html.

( Smashing Magazine, Server Push )

Прежде чем понять, как Server Push может помочь улучшить скорость страницы, важно понять, как браузер работает с различными ресурсами, такими как изображения, CSS и JavaScript, которые отображаются в вашем браузере. Видите ли, браузер отправляет инструкции о том, как загружать изображения, ресурсы CSS и JavaScript. При первом посещении веб-сайта вы обычно делаете запрос GET, который представляет собой файл .html. Как только этот файл .html получен, браузер просматривает его, чтобы понять, а затем может делать дополнительные запросы GET в зависимости от того, что содержится в файле HTML.

Как Server Push помогает повысить скорость страницы?

Благодаря использованию Server Push количество GET-запросов, необходимых от браузера (в оба конца), уменьшается, а задержки рендеринга, приводящие к увеличению времени загрузки страницы, избегаются. Это может значительно улучшить время рендеринга для веб-клиента, что помогает пользователям быстрее отображать веб-страницу, тем самым предоставляя им гораздо лучший опыт.

Хотя Server Push не влияет напрямую на то, как Googlebot сканирует ваш сайт или другие поисковые роботы, преимущество SEO достигается за счет улучшения ориентированных на пользователя факторов, таких как First Paint и First Meaningful Content.

Используя Web Page Test, Lighthouse, Page Speed ​​Insights и Chrome User Experience Report, вы можете определить, насколько сайт/страница работает по сравнению с конкурентами в тех же отраслях. Ниже приведены два изображения, демонстрирующие реализацию без (Изображение 1) и с использованием Server Push (Изображение 2).

(Тест веб-страницы, без отправки сервера)

(Тест веб-страницы, HTTP/1.1, с отправкой на сервер)

С серверной отправкой сервер можно настроить так, чтобы он всегда отправлял любые дополнительные компоненты страницы (такие как файлы CSS, JavaScript и изображения), если его просят отправить файл .html, содержащий их.

В водопадах выше мы видим, что push.php использует четыре файла CSS.

Без сервера push браузер должен получить файл push.php, проанализировать HTML, а затем сделать определенные запросы для каждого дополнительного файла CSS. Только после того, как он получит все файлы CSS, он сможет начать использовать их в процессе рендеринга.

Когда серверная отправка включена, запрос push.php автоматически запускает сервер для отправки четырех файлов CSS. Браузер получает их и может начать использовать их в процессе рендеринга намного раньше. Это означает, что браузер может начать отображать содержимое страницы намного раньше, что приводит к лучшим показателям скорости страницы.

Приоритизация HTTP/2

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

Если мы посмотрим на предшественника HTTP/2 HTTP/1.1, веб-клиент контролировал порядок загрузки ресурсов. Как обсуждалось выше, это было связано с тем, что каждое TCP-соединение могло поддерживать только один ресурс за раз. Браузер должен планировать запросы, решая, какие ресурсы выбрать и сколько подключений открывать параллельно.

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

Если у нас есть изображение вверху страницы и изображение внизу страницы, по логике вещей мы хотели бы убедиться, что изображение вверху загружается раньше, чем изображение внизу. Эта концепция помогает продемонстрировать важность и влияние расстановки приоритетов HTTP/2. Приоритизация HTTP/2 позволяет нам указать, какие ресурсы должны быть доставлены первыми и загружены раньше других (будь то JavaScript, CSS или изображения), что обеспечивает максимально быстрое время загрузки страницы.

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

Поток: это двунаправленный поток байтов внутри установленного соединения, который может передавать одно или несколько сообщений.

Родительский поток: это поток, от которого зависят ресурсы.

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

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

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

Кадр заголовков: это идентификация потока, к которому он принадлежит .

Уровень двоичного кадрирования: именно так HTTP-сообщения инкапсулируются и передаются между клиентом и сервером .

Пример ниже демонстрирует пример вышеизложенного:

( Google Developers HTTP / 2 Stream Priority )

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

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

Приоритет HTTP/2 — общая совместимость с сервером/хостингом/CDN

Это сравнение было правильным на 01.02.2020 , но стоит проверить, улучшили ли потенциальные поставщики услуг свою совместимость, прежде чем принимать решение о том, что выбрать.

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

Совместимость веб-клиента с приоритетом HTTP/2

Приоритет HTTP/2 может значительно улучшить восприятие пользователем скорости страницы/сайта и положительно повлияет на данные, собранные в отчете о пользовательском опыте Chrome. Хотя эта оптимизация не влияет на поисковые роботы, такие как Googlebot, такие инструменты, как Lighthouse и Page Speed ​​Insights , помогут вам оценить влияние приоритизации HTTP/2 на производительность скорости страницы с точки зрения пользователя.

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

Каковы предварительные условия для HTTP/2

Прежде чем вы сможете воспользоваться преимуществами скорости HTTP/2, убедитесь, что вы можете его использовать. Есть несколько предпосылок, которые необходимо учитывать:

  1. Важно убедиться, что HTTPS включен.
  2. Используйте сертификат TLS от аутентифицированного центра, активируйте и установите сертификат.
  3. Убедитесь, что программное обеспечение вашего веб-сервера, такое как Nginx, Apache и IIS, поддерживает HTTP/2. Полный аутентифицированный список для поддержки можно найти по адресу http://ayi.ma/browsershttp2 , где будет показана поддержка браузером HTTP/2. Если вам нужна поддержка HTTP/2 для CDN/хостинга, обратитесь к http://ayi.ma/serverhosting .

Общие ловушки / вещи, которые должны измениться с введением HTTP/2

Из-за ограничений более ранних протоколов HTTP 1.0 и HTTP 1.1 разработчики и SEO-специалисты стремились найти способы обойти множество проблем, которые эти ограничения представляли для производительности и безопасности страницы.

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

Избегайте разделения домена

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

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

Кроме того, с помощью разделения домена вы фактически нарушаете приоритезацию потоков, и ваши ресурсы не смогут загружаться, чтобы получить максимальную отдачу от Page Speed.

Правильно используйте Server Push

Server Push имеет некоторые недостатки, о которых вы должны знать. На самом деле Server Push можно использовать слишком часто, и вы должны быть избирательны при выборе времени его использования. Вы не обязательно хотите передавать слишком много ресурсов, так как это может привести к тому, что веб-клиент загрузит не только HTML, но и все, с чем он «проталкивается». Это означает, что на самом деле загрузка и отображение страницы может занимать больше времени (увеличение ориентированных на пользователя показателей, на которые ориентируется Google, таких как время до взаимодействия).

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

Реальные тесты под HTTP/2

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

Во второй части этой серии статей о скорости страницы HTTP/2 в реальной жизни — использование тестов и анализа веб -сайтов будет обсуждаться истинное преимущество HTTP/2 в отношении скорости страницы и ценности для SEO, так что не пропустите!

А как насчет HTTP/3?

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