Зачем использовать спрайт-лист, а не отдельные изображения? - PullRequest
Новая
       35

Зачем использовать спрайт-лист, а не отдельные изображения?

27 голосов
/ 08 ноября 2011

Одна вещь, которую я заметил на некоторых сайтах, состоит в том, что они используют одно изображение BIIIIIIIG, содержащее множество маленьких изображений, а затем используют CSS background-position для определения координат каждого изображения, а не используют отдельные изображения.

Вот где я нахожусь:

Минусы для использования большого спрайт-листа

  • Необходимо загрузить большое изображение, чтобы отобразить хотя бы одно маленькое изображение
  • Необходимо написать (или сгенерировать) длинную таблицу стилей с классом для каждого изображения
  • Загромождение CSS множеством определений классов может повлиять на производительность
  • Если одно изображение изменяется (или добавляется другое), могут возникнуть проблемы с кэшированием как на изображении, так и на связанном с ним CSS
  • Требуется <div> с правильным стилем (display: inline-block; width: 32px; height: 32px; background-image: url('spritesheet.png');), который добавляет еще один класс к миксу.
  • Еще много чего не помню сейчас, я их печатаю.

Плюсы использования большого спрайт-листа

  • ... Хм ... пока нет.

Фактически, единственное, что здесь близко к профессионалу, это то, что когда я разрезал лист на отдельные изображения, результирующая папка занимала 3Mb на диске (из-за того, что каждый файл был <100 байт и мой размер размещения 4к). Сами по себе файлы имеют размер меньше половины листа и CSS, поэтому <strong> даже при накладных расходах на HTTP-запрос значительно экономит место .

По сути, мой вопрос таков: есть ли у кого-нибудь профессионалы в использовании большого листа для отдельных изображений?

Ответы [ 8 ]

19 голосов
/ 08 ноября 2011

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

Недавно у меня был веб-сайт с множеством прозрачных градиентов (белый с транс, серый с транс) и немного черного и белого на прозрачных изображениях. Поместив их в спрайт и уменьшив цвета в png до 8, я мог получить спрайт меньше по размеру файла, чем исходные изображения (просто ... это было примерно на 0,5% экономии). Сокращение количества HTTP-запросов с 10 до 1 означало, что сайт загружался быстрее (если измерять время от первого соединения до всех передаваемых данных).

В этом случае было обнаружено измеримое увеличение.

Я согласен с тем, что возможно все испортить и получить больший спрайт, чем нужно, особенно если вы не используете сжатие PNG.

Обратите внимание, что через два года после публикации этого сообщения - если вы используете SSL, вам следует обратиться к SPDY (в моей заметке через два года будет упоминаться HTTP 2.0 вместо SPDY!). SPDY сводит на нет преимущества спрайтов.

9 голосов
/ 08 ноября 2011

Немного из того, что вы сказали как о минусах, на самом деле вообще минусы.

Когда вы загружаете одно большое изображение, оно содержит только один из различных атрибутов, которые нужны изображению (таблица цветов, тип пантомимы и т. Д.: представьте, что если вы используете прогрессивный формат jpg, одна таблица спрайтов позволит сканировать изображение один раз, тогда как многие значительно уменьшат время загрузки) вместо того, чтобы иметь одну и ту же информацию в 100 разных файлах, это уменьшит размер файла в большомpicture.

Также будет только ОДИН запрос http (или два, в зависимости от того, сколько у вас спрайтов). Но при правильной обработке только один на каждую загрузку страницы.

Если вы используетеbg изображений в CSS, тогда вы уже сделали селекторы css , так что нет никакой дополнительной работы, просто скопируйте / вставьте URL.

Я никогда не сталкивался с проблемами кеширования со спрайтами, которыене может быть решена нажатием ctrl + F5.

В любом случае это не требует div с правильным стилем.Это не метод замены тега <img>, он используется в основном для изображений bg.Как для кнопок и наборов иконок.

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

Если у кого-то есть что-то еще, не стесняйтесь:)

4 голосов
/ 08 ноября 2011

Google описывает это здесь .В основном это должно сократить время загрузки страницы.Каждая новая инициализация соединения добавляет некоторую задержку.В некоторых случаях это также может уменьшить размер передаваемых данных и, следовательно, сократить время загрузки страницы.Подходит для изображений, которые меняются редко или все вместе (темы).Затем браузер может использовать кэшированное изображение и должен проверять только один файл на наличие изменений, а не каждое изображение одно за другим.

3 голосов
/ 28 сентября 2013

Спрайт листы беспорядок. Период. Не нужно приукрашивать его. Они представляют огромный шаг назад в технологии проектирования, что, вероятно, объясняет, почему единственные люди, которым нравится использовать спрайт-листы, - разработчики игр старой школы. Листы Sprite имеют только одно качество выкупа, они загружаются немного быстрее. Кроме этого, они мусор. Не говоря уже о кошмаре, чтобы настроить.

В каком мире «приемлемо» включать 500 строк кода, чтобы запустить простой цикл ходьбы. Надеемся, что некоторые умные ребята придумают такое простое решение, как перетаскивание автономного формата видео с альфа-поддержкой, такого как flv, но оно также будет работать на планшетах ...

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

1 голос
/ 17 ноября 2011

Кроме того, это помогает поддерживать чистоту в CSS. Например, я использую спрайты для кнопок (что также означает отсутствие дополнительной задержки для загрузки состояния наведения img) 

<button type="submit" class="vorige"><span>Vorige</span></button>

button  {display: block; width: 162px; height: 47px; background-position: 0 0;}
button:hover    {background-position: 0 94px; cursor: pointer;}
button:active   {background-position: 0 47px;}
button span {display: none}

.vorige     {background-image: url(../img/button/btn_vorige.png);}
.volgende   {background-image: url(../img/button/btn_volgende.png);}
.verstuur   {background-image: url(../img/button/btn_verstuur.png);}

из-за спрайта я могу пропустить код для отдельного изображения при наведении курсора: 

.vorige:hover   {background-image: url(../img/button/btn_vorige_active.png);}
.volgende:hover {background-image: url(../img/button/btn_volgende_active.png);}
.verstuur:hover {background-image: url(../img/button/btn_verstuur_active.png);}
1 голос
/ 08 ноября 2011

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

Все дело в скорости загрузки.Только один http-запрос выполняется быстрее, чем десятки из них.

1 голос
/ 08 ноября 2011

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

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

1 голос
/ 08 ноября 2011

Да - количество запросов.

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

...