Я читал в комплекте частей документации systemjs, что оптимизация пакетов, больше не требуемая в HTTP/2:
В отношении HTTP/2 этот подход может быть предпочтительным, поскольку он позволяет файлам индивидуально кэшируется в браузере, что означает, что оптимизация пакетов не является более долгое беспокойство.
Мои вопросы:
HTTP/2 поддерживает "push-сервер", который устаревает связывание ресурсов. Итак, да, если вы используете HTTP/2, объединение фактически будет анти-шаблоном.
Для получения дополнительной информации проверьте это: https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/
Оптимизация связывания была введена как "лучшая практика" при использовании HTTP/1.1, поскольку браузеры могли открывать только ограниченное количество подключений к определенному домену.
Типичная веб-страница имеет 30+ ресурсов для загрузки для рендеринга. С помощью HTTP/1.1 браузер открывает 6 подключений к серверу, запрашивает 6 ресурсов параллельно, дожидается загрузки, затем запрашивает другие 6 ресурсов и т.д. (Или, конечно, какой-то ресурс будет загружен быстрее других, и это соединение может быть повторно использован раньше, чем другие для другого запроса). Дело в том, что с HTTP/1.1 вы можете получить не более 6 невыполненных запросов.
Чтобы загрузить 30 ресурсов, вам понадобится 5 обращений, что добавит много латентности для рендеринга страницы.
Чтобы сделать рендеринг страницы быстрее, с помощью HTTP/1.1 разработчику приложения пришлось сократить количество запросов на одну страницу. Это приводит к "передовым методам", таким как клонирование домена, встраивание ресурсов, написание образов, объединение ресурсов и т.д., Но на самом деле это просто умные взломы для обхода ограничений протокола HTTP/1.1.
С HTTP/2 вещи разные, потому что HTTP/2 мультиплексируется. Даже без HTTP/2 Push функция мультиплексирования HTTP/2 делает все эти хаки бесполезными, потому что теперь вы можете запрашивать сотни ресурсов параллельно с использованием одного TCP-соединения.
С помощью HTTP/2 для тех же 30 ресурсов потребуется всего одна обратная связь, которая будет загружена, что даст вам 5-кратное увеличение производительности в этой операции (что обычно доминирует над временем рендеринга страницы).
Учитывая, что тенденция веб-контента должна быть богаче, у него будет больше ресурсов; чем больше ресурсов, тем лучше HTTP/2 будет работать в отношении HTTP/1.1.
Помимо мультиплексирования HTTP/2 у вас есть HTTP/2 Push.
Без HTTP/2 Push браузер должен запросить основной ресурс (страница *.html), загрузить его, проанализировать, а затем организовать загрузку 30 ресурсов, на которые ссылается основной ресурс.
HTTP/2 Push позволяет вам получить 30 ресурсов, пока вы запрашиваете основной ресурс, который ссылается на них, сохраняя еще один кругооборот, снова благодаря мультиплексированию HTTP/2.
На самом деле функция мультиплексирования HTTP/2 позволяет забыть о сбое ресурсов.
Вы можете посмотреть slides сеанса HTTP/2, который я дал на разных конференциях.
Связывание по-прежнему полезно, если ваш веб-сайт
Есть две функции HTTP 2.0, которые делают устаревшее связывание:
PS: Объединение - это не единственный метод оптимизации, который будет устранен в результате восстания функций HTTP 2.0. Особенности, такие как написание изображений, очертание домена и вложение ресурсов > (Встраивание изображений через URI данных).
Связывание делает много в современной сборке JavaScript. HTTP/2 решает только оптимизацию минимизации количества запросов между клиентом и сервером, делая стоимость дополнительных запросов намного дешевле, чем с помощью HTTP/1
Но объединение сегодня заключается не только в минимизации количества запросов между клиентом и сервером. Два других важных аспекта:
Кроме того, HTTP/2-серверный канал может тратить пропускную способность, нажимая ресурсы, которые браузер не нужен, потому что он все еще имеет их в кеше.
Две хорошие сообщения по теме:
Оба этих сообщения приходят к выводу, что "строить процессы здесь, чтобы остаться".