Готовимся к HTTP/2: Руководство для веб-дизайнеров и разработчиков

http2Протокол передачи гипертекста (HTTP, англ. HyperText Transfer Protocol) - протокол, который управляет соединением между вашим сервером и браузерами клиентов. Впервые после 1999 года, появилась новая версия этого протокола, и это обещает значительно ускорить каждый сайт.

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

Для дальнейшего прочтения

(на сайте оригинала):

Краткая история HTTP.

HTTP - старый протокол, изначально описан в 1991, последнее крупное обновление HTTP/1.1 вышло в 1999. В 1999 году сайты очень сильно отличались от современных. В статье http2 explained, Daniel Sternberg объясняет, что при открытии страницы современного сайта, в среднем нужно загрузить 1.9 Мб контента из порядка 100 разных ресурсов, где "ресурсы" - что угодно, начиная картинками и шрифтами, и заканчивая js- и css-файлами.

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

SPDY

В 2009 году, два инженера из Google написали об исследовательском проекте SPDY, над которым они работали. Этот проект решал некоторые проблемы HTTP/1.1. Предполагалось, что SPDY:

  • разрешит параллельные запросы через одно TCP соединение, известно как мультиплексирование;
  • позволит браузерам загружать ассеты с разным приоритетом, что позволит серверу отдавать вначале жизненно важные ресурсы;
  • будет сжимать/уменьшит количество http хедеров;
  • реализует "серверный пуш", посредством которого сервер сможет отправлять жизненно важные ресурсы до их запроса браузером.

Кроме того, SPDY требует https соединение.

SPDY не замещает HTTP, он скорее туннелирует протокол и изменяет привычный способ отправки запроса/ответа. Он требует двусторонней поддержки со стороны клиента и сервера. Многие использовали технологию, благодаря поддержки Nginx и пакетов от Google для включения поддержки в Apache. Поддержка браузерами тоже довольно неплохая, все новые версии основных браузеров поддерживают SPDY.

HTTP/2

Как видим, SPDY имеет определенный успех, приобретая приятие как серверами, так и браузерами. Однако, вы также могли заметить, что несмотря на то, что Internet Explorer 11 поддерживает SPDY, у Microsoft’s Edge поддержка упразднена. Что же произошло?

Отказ от поддержки SPDY у Microsoft’s Edge обусловлен тем, что Microsoft реализовали поддержку HTTP/2, новой версии HTTP протокола. В то время другие современные браузеры продолжают поддержку SPDY, Crome откажется от поддержки в 2016, остальные, скорее всего, будут продолжать поддерживать. Во время написания, Edge, Firefox, Chrome и Opera поддерживают и SPDY, и HTTP/2. Safari, включая версию для iOS присоединятся к этой группе позже в этом году с выпуском Safary 9.

HTTP/2 построен на успехе SPDY, он же стал основой для нового протокола. Таким образом, большинство целей SPDY достигнуты в HTTP/2. Требование https соединения было отброшено. Тем не менее, все разработчики браузеров решили реализовать HTTP/2 для TLS (https) соединений. Так что не смотря на то, что теоретически вы можете использовать HTTP/2 с простым текстом, наш случай использования подразумевает, что ваш сайт уже использует https.

Разработка HTTP/2 спецификации была завершена в феврале 2015. Через год, поддержка современными браузерами отличная. Так же как и SPDY, HTTP/2 требует поддержки как со стороны браузера, так и со стороны сервера, у существует уже много серверных решений. Можете посмотреть историю в HTTP/2 wiki. У 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, вы также должны знать, пользуются ли ваши посетители браузерами, поддерживающими новый стандарт. Владельцы сайтов, посетители которых пользуются современными браузерами смогут сделать переход намного быстрее, чем сайтов, имеющих много посещений со старых браузеров. Чтобы решить эту проблему, я также дам несколько советов, что делать в этом переходном периоде.

Перейдите на TLC

Для многих сайтов тяжелее всего не перейти на HTTP/2, а использовать защищенное соединение. Если вы разрабатывает новый, или обновляете старый сайт, первое, что вы должны сделать как можно скорее - это использовать https. Это важно не только для HTTP/2, Google выше ранжирует сайты с https-соединением, браузеры помечают не https-сайты как "небезопасные". В будущем вы обнаружите, что множество html5 фич, к примеру, геолокация, недоступны без защищенного соединения.

Если у ваш сайт использует только http, тогда мое предложение как можно скорее перейти на https, и уже тогда определится с HTTP/2 стратегией.

Объединение множества изображений в спрайты

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

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

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

Встраивание изображений за счет использования data uri

Другое обходное решение проблемы множества HTTP-запросов - встраивание изображений в css с использованием data uri. Использование изображений подобным способом делает css-файл намного больше. Если вы в добавок используете сжатие и объединение ассетов, посетители будут загружать огромное количество кода, даже если никогда не перейдут на страницу, где он действительно нужен.

С оптимизацией HTTP-запросов у HTTP/2, эта "лучшая практика" будет больше мешать, нежели помогать улучшению производительности.

Объединение CSS и Javascript

Многие из нас используют объединение мелких css и javascript файлов. Зачастую мы хотим содержать их раздельно во время разработки - для лучшего понимания, но мы знаем, что загрузка одного файла браузером намного эффективней, чем пяти. Еще раз, мы ограничиваем количество HTTP-запросов.

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

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

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

Распределение ресурсов между хостами: sharding

C HTTP/1.1, вы ограничены количеством открытых соединений. Если невозможно избежать загрузки, один из способов решения проблемы - получение ресурсов с разных доменов. Эта методика называется domain sharding. Это хотя и ускоряет время загрузки, но может вызвать новые проблемы, не говоря уже о том, что это требует дополнительных расходов во время разработки.

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

Как теперь подготовиться до HTTP/2?

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

Создайте индивидуальные ассеты, дополнительно до спрайтов и data uri

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

Это также касается и data uri. Если используете в css, подготовьте также картинки для того времени, когда вы откажетесь от этой техники.

Упорядочьте ассеты по разделам сайта

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

Управление domain sharding

Текущая лучшая практика для HTTP/1.1 - ограничение sharding двумя хостами. В HTTP/2 возможно объединить соединения, если TLS сертификат валидный для обеих хостов и хост резолвится для одного IP-адресса. Поскольку браузерная реализация требует, чтобы HTTP/2 работал через https, необходимо получить TLS сертификат, чтобы использовать HTTP/2. Посмотрите больше на 26 слайде Ilya Grigorik’s с Velocity Conference.

Это далеко не все

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

Когда переключиться?

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

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

Вам нужно будет принять решение, пользуясь данными аналитики. Если большинство пользователей использует браузеры, которые поддерживают HTTP/2, тогда есть смысл оптимизировать под этих пользователей. Многие из на уже достигли этого момента. Вам нужно использовать данные с таких сайтов, как Can I Use вместе с данными, собираемыми с собственной аналитики и понимания интересов аудитории. К примеру, большинство преимуществ HTTP/2 почувствуют пользователи мобильных устройств. Если у вас больше мобильного трафика, это может свидетельствовать о необходимости ближайшего перехода. Однако, если много пользователей используют Opera Mini, тогда нужно повременить с переходом на HTTP/2, так как, несмотря на множество пользователей в некоторых странах мира, этот браузер не поддерживает новый стандарт.

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

План действий по работе с HTTP/2

1. Запустите проект, или перейдите но TLS сейчас.

Это должно быть вашим приоритетом.

2. Подготовьте ваш процесс сборки до HTTP/2.

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

3. Проверьте вашу статистику

Проверив статистику использования браузеров и таблицу совместимости Can I Use, вы сможете увидеть, сколько процентов посетителей получать преимущества при оптимизации под HTTP/2.

4. Проверьте свой хостинг

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

5. Займитесь оптимизацией под HTTP/2.

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

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

Узнать больше

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

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

Эта свободная электронная книга очень хорошая для прочтения, если хотите углубится в детали протокола как плана или стратегии.

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

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

Этот плагин для браузера показывает, работает ли сайт с HTTP/2.


Оригинал By Rachel Andrew

24/03/2016 Web-программирование 4969