Подготовка к HTTP2: руководство для веб-дизайнеров и разработчиков
Опубликовано: 2022-03-10Протокол передачи гипертекста (HTTP) — это протокол, который управляет соединением между вашим сервером и браузерами посетителей вашего веб-сайта. Впервые с 1999 года у нас есть новая версия этого протокола , и она обещает гораздо более быстрые веб-сайты для всех.
В этой статье мы рассмотрим основы HTTP2 применительно к веб-дизайнерам и разработчикам. Я объясню некоторые ключевые особенности нового протокола , рассмотрю совместимость браузеров и серверов и подробно расскажу о вещах, о которых вам, возможно, придется подумать, поскольку мы наблюдаем более широкое распространение HTTP2.
Дальнейшее чтение о Smashing:
- Предварительная загрузка: для чего это нужно?
- Все, что вам нужно знать об AMP
- Улучшение производительности Smashing Magazine
Прочитав эту статью, вы получите общее представление о том, что следует изменить в вашем рабочем процессе в краткосрочной и долгосрочной перспективе. Я также включу множество ресурсов, если вы хотите углубиться в поднятые вопросы. Моя цель — дать вам достаточно информации, чтобы вы могли принимать правильные решения при планировании перехода на HTTP2.
Краткая история HTTP
HTTP — это старый протокол, первоначально определенный в 1991 году, последняя основная версия — HTTP/1.1 — была опубликована в 1999 году. Веб-сайты 1999 года сильно отличались от веб-сайтов, которые мы разрабатываем сегодня. В объяснении http2 Даниэль Штернберг отмечает, что объем данных, необходимых сейчас для загрузки домашней страницы среднего веб-сайта, составляет 1,9 МБ, при этом для отображения страницы требуется более 100 отдельных ресурсов — «ресурсом» может быть любое изображение или шрифт. в файл JavaScript или CSS.
HTTP/1.1 плохо работает при извлечении большого количества ресурсов, необходимых для отображения современного веб-сайта. Как мы увидим позже в этой статье, многие передовые методы повышения производительности, известные нам как веб-разработчикам, основаны на том, что мы справляемся с ограничениями HTTP/1.1.
СПДИ
В 2009 году два инженера Google опубликовали сообщение об исследовательском проекте SPDY, над которым они работали. В этом проекте были устранены некоторые проблемы в HTTP/1.1. SPDY поставила перед собой цель:
- разрешить одновременные запросы через одно соединение TCP, известное как мультиплексирование ;
- разрешить браузерам расставлять приоритеты для активов, чтобы ресурсы, жизненно важные для отображения страницы, могли быть отправлены сервером в первую очередь;
- сжимать и уменьшать заголовки HTTP;
- внедрить server push , благодаря чему сервер может передавать жизненно важные ресурсы в браузер до того, как их запросят.
Кроме того, SPDY требует зашифрованного (HTTPS) соединения между браузером и сервером.
SPDY не заменяет HTTP; скорее, это туннель для протокола, который изменяет способ отправки существующих HTTP-запросов и ответов. Для этого требуется поддержка как со стороны сервера, так и со стороны браузера , подключающегося к этому серверу. С поддержкой, доступной в NGINX, и пакетами, доступными от Google, чтобы включить поддержку в Apache, SPDY был принят в разумных пределах. Поддержка браузеров также довольно хороша, ее поддерживают современные версии всех основных браузеров.
![Информация о поддержке браузера SPDY на Могу ли я использовать](/uploads/article/1293/BCiPWK5ftaoCFZux.png)
HTTP2
Мы видели, как SPDY добился определенного успеха, получив признание как на серверах, так и в браузерах. Однако вы также могли заметить, что, несмотря на поддержку Internet Explorer 11, браузер Microsoft Edge отказался от него. Что тут происходит?
Поддержка SPDY была прекращена в Edge из-за того, что Microsoft реализовала поддержку HTTP2, последней версии протокола HTTP. В то время как другие современные браузеры по-прежнему поддерживают SPDY, Chrome прекратит поддержку в 2016 году, и другие браузеры, скорее всего, последуют этому примеру. На момент написания статьи Edge, Firefox, Chrome и Opera поддерживали как SPDY, так и HTTP2. Safari, в том числе на iOS, присоединится к этой группе позже в этом году с запуском Safari 9.
![Информация о поддержке браузера SPDY на Могу ли я использовать](/uploads/article/1293/O2zLE6q5BLNcpQ9H.png)
HTTP2 основывается на успехе SPDY, который использовался в качестве отправной точки для нового протокола. Таким образом, большинство целей SPDY достигаются в HTTP/2. Требование к HTTPS-соединению было снято. Тем не менее, все поставщики браузеров решили реализовать HTTP2 только для соединений TLS (https). Таким образом, хотя вы потенциально можете использовать HTTP/2 с открытым текстом при обмене данными между серверами, наш вариант использования HTTP2 для браузеров означает, что вам нужно, чтобы ваш сайт работал на https, прежде чем вы даже подумаете о переходе на HTTP2.
Спецификация HTTP2 была завершена в феврале 2015 года; год спустя поддержка браузеров в современных браузерах превосходна. Как и в случае с SPDY, HTTP2 требует поддержки как на уровне браузера, так и на уровне сервера, и уже существует множество реализаций веб-сервера. Вы можете отслеживать их на вики HTTP/2. У W3Techs также есть сообщение от июля 2015 года с подробным описанием темпов внедрения. Принятие этого протокола происходит быстро, учитывая, насколько он относительно новый.
Придется ли нам менять наши веб-сайты?
HTTP/2 обратно совместим с HTTP/1.1 , поэтому его можно было бы полностью игнорировать, и все будет продолжать работать как прежде. Изменение протокола полностью прозрачно для пользователей. Многие читатели этой статьи уже много лет используют протокол, отличный от HTTP/1.1. Если у вас есть учетная запись Gmail и вы используете Chrome для доступа к ней, вы использовали SPDY, а затем HTTP/2, ничего об этом не зная.
Однако многие вещи, которые вы считаете лучшими практиками, могут отрицательно сказаться на производительности в HTTP/2. Со временем, по мере того как все больше серверов будут обновляться для использования HTTP/2 и все больше людей будут использовать браузеры, поддерживающие HTTP/2, ваш веб-сайт, когда-то хорошо оптимизированный в соответствии с лучшими практиками, начнет казаться медленнее, чем веб-сайты, оптимизированные для нового протокола.
Что нам нужно изменить, чтобы принять HTTP/2?
В оставшейся части этой статьи мы рассмотрим некоторые из распространенных передовых практик, которые станут антишаблонами по мере принятия HTTP/2 . Как мы видели, переход будет медленным для многих веб-сайтов. Чтобы перейти на HTTP/2, программное обеспечение вашего сервера необходимо будет обновить для поддержки протокола, что может быть легко или почти невозможно в зависимости от того, как вы размещаетесь.
Прежде чем вносить изменения на свой веб-сайт специально для HTTP/2, вам также необходимо подумать, поддерживают ли ваши посетители браузеры. Владельцы веб-сайтов, которые привлекают много людей, использующих самые современные браузеры, смогут сделать этот переход раньше, чем владельцы, журналы которых показывают, что большинство пользователей используют более старые браузеры. Чтобы отразить это, я также дам вам несколько советов о том, как работать в этот переходный период.
Сделайте переход на TLS
Для многих веб-сайтов самым сложным при переходе на HTTP/2 может быть вовсе не HTTP/2, а требование запуска сайта через безопасное соединение. Если вы разрабатываете новый сайт или обновляете старый, ваш первый шаг должен состоять в том, чтобы убедиться, что вы запускаете или переходите на https как можно скорее. Это важно не только для HTTP/2, Google использует безопасные соединения в качестве сигнала ранжирования, а браузеры начинают помечать веб-сайты без https как «небезопасные». В будущем вы обнаружите, что некоторые мощные функции HTML5, такие как геолокация, недоступны без безопасного соединения.
Если у вас есть сайт, который в настоящее время работает только по протоколу HTTP, то я предлагаю сначала установить приоритет перехода на https, а затем выбрать стратегию HTTP/2.
Превращение нескольких файлов изображений в спрайты
В HTTP 1.1 извлечение одного большого изображения намного эффективнее для браузера, чем множество запросов для маленьких. Это связано с тем, что несколько запросов стоят в очереди друг за другом. Чтобы обойти это, нам посоветовали превратить наши маленькие значки в файл спрайтов.
Результирующий спрайт возвращается с одним HTTP-запросом, что предотвращает проблему постановки в очередь нескольких запросов. Однако, даже если посетитель находится на странице, на которой показан только один из этих значков, ему все равно придется загрузить файл гораздо большего размера, чем нужно, чтобы увидеть это изображение.
Благодаря возможности мультиплексирования HTTP/2 эта очередь ресурсов больше не является проблемой. Во многих случаях будет лучше обслуживать небольшие изображения по отдельности; вам нужно будет обслуживать только то, что требуется для страницы, на которой находится посетитель. В некоторых случаях создание спрайта по-прежнему оправдано; HTTP-запросы — это только один из аспектов производительности. Объединение некоторых изображений вместе в спрайт может обеспечить лучшее сжатие и, следовательно, меньший общий размер загрузки, особенно если все эти изображения используются на загружаемой странице. Однако спрайт больше не будет лучшим выбором.
Встраивание изображений с использованием URI данных
Еще один обходной путь для проблемы множественных HTTP-запросов в HTTP/1.1 — встраивание изображений в CSS с использованием URI данных. Встраивание изображений таким образом сделает таблицу стилей намного больше. Если вы объедините это с другим методом оптимизации для объединения ресурсов, то посетитель, скорее всего, загрузит весь этот код, даже если он никогда не посещает страницы, на которых используются изображения.
![](https://s.stat888.com/img/bg.png)
Поскольку HTTP-запросы в HTTP/2 обходятся очень дешево, эта «лучшая практика» скорее снизит, чем поможет производительности.
Объединение CSS и JavaScript
В качестве последнего шага в процессе сборки многие из нас объединят все небольшие файлы CSS и JavaScript, используемые на нашем веб-сайте. Мы часто хотим разделить их при разработке, чтобы упростить управление этими ресурсами, но мы знаем, что доставка одного файла в браузер более эффективна для производительности, чем доставка пяти. Мы снова пытаемся ограничить HTTP-запросы.
Если вы делаете это, то посетитель, попадающий на вашу домашнюю страницу, может загрузить все CSS и JavaScript, необходимые для вашего веб-сайта, даже если он никогда не использует большую их часть. Как разработчик, вы можете обойти эту проблему, тщательно выбрав и включив определенные файлы для каждой области веб-сайта в процесс сборки, но это может потребовать довольно много работы.
Дополнительная проблема с конкатенацией заключается в том, что из кеша нужно будет удалить все сразу. Некоторым файлам, которые никогда не изменяются, нельзя дать длительный срок действия, а часто изменяющимся частям кодовой базы — более короткий срок. Все это должно быть просрочено, если хотя бы одна строка CSS, используемая на одной странице, изменена.
Я думаю, вы видите, к чему все идет! HTTP-запросы дешевы в мире HTTP/2 . Организовывать свои активы во время разработки в соответствии со страницами, на которых они будут использоваться, будет намного лучше. Затем вы можете обслуживать только тот код, который нужен посетителю. Загрузка большого количества крошечных таблиц стилей не имеет значения. Вы также можете организовать на основе того, как часто что-то меняется; активы с долговечностью можно было бы заботиться о них дольше.
Разделение ресурсов между хостами: Шардинг
С HTTP/1.1 вы ограничены количеством открытых подключений. Если загрузка большого количества ресурсов неизбежна, одним из способов обойти это ограничение является получение их из нескольких доменов. Это называется шардингом домена. Это может улучшить время загрузки, но само по себе может вызвать проблемы, не говоря уже о накладных расходах на разработку для подготовки этого для вашего веб-сайта.
HTTP/2 устраняет необходимость в сегментировании домена , поскольку вы можете запрашивать столько ресурсов, сколько вам нужно. На самом деле, этот метод, скорее всего, снизит производительность, поскольку создает дополнительные соединения TCP и не позволяет HTTP/2 расставлять приоритеты для ресурсов.
Как подготовиться к HTTP/2 сейчас
Если вы начинаете проект, который, как вы ожидаете, будет иметь некоторую долговечность, но не может запустить HTTP/2, возможно, из-за поддержки сервера, стоит подумать о том, как вы можете подготовиться к HTTP/2. Теперь вы можете добавить несколько вещей в процесс сборки, которые облегчат переход в дальнейшем.
Создавайте отдельные активы в дополнение к URI спрайтов и данных
Если вы создаете спрайты, добавьте в свой процесс создание и оптимизацию этих отдельных ресурсов или небольших спрайтов для конкретных страниц, если вы считаете, что они лучше всего повысят производительность. Это облегчит вам переход от больших спрайтов к маленьким (или отсутствию) спрайтов, когда будет достигнут переломный момент для вашего сайта.
То же самое относится и к URI данных. Если вы в настоящее время используете их в своем CSS, подготовьте изображения, когда вы откажетесь от этой техники.
Организуйте свои активы по разделам веб-сайта
С конкатенацией CSS и JavaScript возникает искушение оптимизировать для простоты разработки, потому что все файлы все равно будут сжаты вместе. При переходе на HTTP/2 вы получите наилучшую производительность за счет тщательного управления ресурсами , чтобы на эту страницу доставлялись только те вещи, которые необходимы определенной странице. Поэтому начав организовывать свое развитие таким образом уже сейчас, это окупится. На данный момент вы вполне можете по-прежнему выполнять конкатенацию, и когда будет достигнут переломный момент, вы можете остановить эту часть процесса сборки и обслуживать ресурсы по отдельности.
Управление разделением домена
Текущая лучшая практика для HTTP/1.1 — ограничить сегментирование двумя именами хостов. Существует способ заставить HTTP/2 объединять соединения, если сертификат TLS действителен для обоих хостов и хосты разрешают один и тот же IP-адрес. Поскольку разработчики браузеров требуют, чтобы HTTP/2 работал поверх HTTPS, необходимо получить сертификат TLS для работы поверх HTTP/2. Подробнее см. на слайде 26 презентации Ильи Григорика с Velocity Conference.
![Слайд из презентации Ильи Григорика](/uploads/article/1293/wdA7KCaAkTuqCKVr.png)
Еще не все
В конечном итоге мы получим целый ряд лучших практик для HTTP/2. Для достижения наилучшей производительности этот протокол возвращает вам большую часть контроля, а это означает, что вам нужно будет принимать решения для каждого проекта. В этой статье я не рассказал, как воспользоваться преимуществами новых возможностей HTTP/2, таких как отправка на сервер. Эта технология позволяет вам решить, какие ресурсы являются приоритетными, и дает указание серверу передать их перед менее важными вещами.
Когда переключаться?
Дизайнерам и разработчикам, которые не имеют полного контроля над серверами, на которых они развертываются, решение может быть отложено до тех пор, пока используемые ими серверы не будут обновлены. Хостинговые компании уже предлагают HTTP/2 — даже для виртуального хостинга — поэтому развертывание на вспомогательном сервере — это то, что вы можете порекомендовать клиенту, если знаете, что это принесет ему пользу.
Как только ваш веб-сайт будет размещен на сервере, поддерживающем HTTP/2, решение о продолжении оптимизации для HTTP/1.1 или оптимизации для HTTP/2 будет зависеть от протокола, поддерживаемого большинством ваших пользователей . Помните, что HTTP/2 обратно совместим — вам не нужно делать ничего особенного. Решение, которое вам нужно принять, заключается в том, когда оптимизировать его.
Вам нужно будет принять решение в соответствии с вашими аналитическими данными. Если больше посетителей используют браузеры с поддержкой HTTP/2, чем нет, то я бы предположил, что это разумный переломный момент для оптимизации для этих пользователей. Многие из нас уже достигли этой точки. Вы должны использовать данные с таких сайтов, как Can I Use, а также данные, собранные из вашей собственной аналитики и знаний о вашей вероятной аудитории. Например, многие из преимуществ HTTP/2 будут наиболее остро ощущаться пользователями HTTP/2, поддерживающими мобильные устройства. Если у вас высокий процент мобильного трафика, это может быть признаком того, что вам нужно быстрее перейти на HTTP/2. Тем не менее, если у вас высокий процент мобильного трафика от пользователей, просматривающих веб-страницы с помощью Opera Mini, это может быть причиной для того, чтобы отложить переход на HTTP/2, так как в настоящее время он не поддерживается, хотя в некоторых из них присутствует большое количество пользователей. части мира.
Если вы сегодня создаете совершенно новый веб-сайт, я бы посоветовал учитывать оптимизацию HTTP/2 на протяжении всей сборки. Если при запуске вы чувствуете, что вам нужно пойти на уступки для HTTP/1.1 из-за поддержки браузера или сервера, многое из этого можно сделать в процессе сборки, что позволит вам переключиться на версию HTTP/2, как только вы почувствуете время правильное.
Ваш план действий по HTTP/2
- Запуск с безопасным подключением или переход на TLS сейчас . Это должно быть вашим приоритетом.
- Подготовьтесь к HTTP/2 в процессе сборки. Любой веб-сайт, который вы создаете сейчас, скорее всего, выиграет от оптимизации для HTTP/2 в течение всего срока его службы. Используйте приведенные выше советы, чтобы создать процесс сборки, который можно оптимизировать для обоих протоколов.
- Проверьте свою статистику. Сравнив использование браузера на вашем веб-сайте с таблицей поддержки на Могу ли я использовать, вы можете увидеть, какой процент посетителей выиграет от оптимизации HTTP/2.
- Проверьте свой хостинг. Когда вы дойдете до того момента, когда вы выиграете от перехода, вам нужно будет убедиться, что ваш сервер поддерживает HTTP/2. Поговорите со своим хостинг-провайдером или администратором сервера, чтобы узнать их план миграции.
- Разверните оптимизацию HTTP/2. Как только ваш сервер поддерживает HTTP/2, все остальное зависит от вас. Прекратите использовать старые лучшие практики и переключитесь на новые. Это будет означать, что пользователи с браузерами, не поддерживающими HTTP/2, будут работать медленнее, поэтому движущая сила вашего изменения должна стать переломным моментом, когда большинство выиграет.
Когда вы перейдете на HTTP/2, было бы интересно сравнить увеличение скорости и посмотреть, какие методы оказали наибольшее влияние на ваши веб-сайты. Я с нетерпением жду информации из реальных случаев, когда люди переносят веб-сайты. Эта информация поможет нам разработать целый ряд передовых практик нового поколения.
Узнать больше
Все больше информации о HTTP/2 доступно в Интернете. Я перечислил здесь некоторые ресурсы для справки, на многие из которых я ссылался при написании этой статьи.
- «Протокол передачи гипертекста версии 2 (HTTP/2)» (спецификация), Internet Engineering Task Force. Это для тех, кто любит читать спецификации или кому нужно разбираться в тонкостях. Для всех остальных FAQ по HTTP/2 — отличное краткое изложение основных функций.
- Объяснение http2 , Даниэль Штернберг Эту бесплатную электронную книгу стоит прочитать, если вы хотите углубиться в детали протокола при планировании своей стратегии.
- High Performance Browser Networking , Илья Григорик, O'Reilly В этой книге рассматриваются лучшие практики HTTP/1.1 и HTTP/2. Это было бы полезно для всех, кто хочет повысить производительность сегодня и подготовиться к будущему.
- «HTTP/2 здесь, давайте оптимизировать» (slidedeck) Илья Григорик Этот превосходный набор слайдов содержит больше информации по некоторым вопросам, затронутым в этой статье.
- Индикатор HTTP/2: Firefox и Chrome Этот плагин для браузера сообщает вам, обслуживается ли веб-сайт, на котором вы находитесь, через HTTP/2.
- Чтобы узнать больше, посмотрите этот огромный список ссылок, составленный Ребеккой Мерфи.