HTTP/2 позволяет мультиплексировать соединения, устраняя необходимость в более чем одном подключении к серверу. По одному соединению многие отдельные изображения могут быть отправлены клиенту. Это устраняет старый шаблон спрайта изображения, объединяющий многие изображения в один, и используя CSS, чтобы разделить его.
Мне любопытно, если спрайты все равно будут быстрее в мире HTTP/2. Если да, то при каких обстоятельствах?
Спрайты, как вам известно, используются для предотвращения очередности множества запросов, поэтому с одной полезной нагрузкой вы можете получить все спрайты для сайта.
Но с спрайтами вы, как правило, получаете много дополнительных значков, которые используются на веб-сайте, которые не нужны ни на одной странице.
Таким образом, при мультиплексировании http/2 ресурсы очередей больше не являются проблемой. Вы получаете выгоду от скорости при загрузке файлов, необходимых для каждой страницы.
Однако вы можете улучшить сжатие, объединив некоторые изображения в один файл, уменьшив общий размер передачи файлов.
Тесты скорости, проведенные Benoît Béraud и Alexandre Masselot, привели пример загрузки спрайта, который был быстрее, чем отдельные спрайты. Они пришли к выводу, что наборы спрайтов по-прежнему могут использоваться для оптимизации производительности сайта при использовании http/2 http://blog.octo.com/en/http2-arrives-but-sprite-sets-aint-no-dead/
Расширенные записи о http/2 от Рэйчел Эндрю можно найти здесь: https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/
С мультиплексированием HTTP/2 сервер будет считывать множество небольших файлов вместо чтения одного большого файла. Если сервер ограничен ресурсами (например, для некоторых приложений Internet-of-Things), тогда вы сможете найти ситуацию, когда лучше сделать это, делая одно, большое чтение, а не много маленьких, поскольку каждое чтение заставляет серверную ОС потенциально выполнять множество операций, связанных с доступом к файлам.
На стороне клиента браузер будет управлять большим количеством небольших файлов, а не большой. Я могу представить, что путь кода, используемый для текущего рабочего процесса спрайтов, хорошо массируется и оптимизируется, поскольку он так часто используется. Так что может случиться так, что новый случай наличия большого количества небольших файлов может быть медленнее, по крайней мере на какое-то время.