Статьи

Автор: Мациевский Николай aka sunnybear
Опубликована: 30 июня 2008

CSS Sprites — зло, не используйте их!

После многочисленных статей (на русском и английском) на тему использования стилей для Rollover-эффектов, уменьшения задержки при открытии страницы и нагрузки на сервер, я хочу раскритиковать использование CSS Sprites. В качестве более зрелого и мощного способа можно предложить использование data:URL и ряд дополнительных методик. На мой взгляд, область применения CSS Sprites весьма ограничена, я хочу постараться обозначить ее данной статьей и указать, когда их лучше не использовать.

Проблемы при верстке

С какими проблемами сталкивается верстальщик, когда использует спрайты? Это, в первую очередь, проблемы изменения каждой конкретной картинки в общем массиве. Мало того, что нужно открыть ресурсную картинку, найти в ней область, соответствующую данному небольшому изображению (которое меняется), и заменить ее, не потеряв палитру при всех изменениях. Также при изменении расположения картинок в ресурсном файле (например, перераспределили свободное место в связи с очередными дизайнерскими изменениями) нужно заново пересчитать все координаты и внести соответствия в CSS-файл.

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

Google Sprites

Спасибо посмотреть профиль rsa, также у IE возникают проблемы с позиционированием полупрозрачных PNG-картинок (которые нужно вставлять через AlpaImageLoader). Таким образом, больше одной такой картинки в спрайт не добавить (в левый верхний угол).Спасибо посмотреть профиль sirus, это можно обойти при помощи crop или, как указал посмотреть профиль pepelsbey, абсолютного позиционирования и дополнительной разметки.

Проблемы при загрузке

Казалось бы, CSS Sprites призваны уменьшить задержку при загрузке страницы, однако, на практике так происходит только при правильном подходе. Обычно в ресурсную картинку кидается все подряд, картинка многократно увеличивается, а визуальная задержка при загрузке сайта может и возрасти: пользовать может ждать 1 большую картинку дольше, чем половину входящих в нее маленьких, а последние обеспечат ему «почти» загрузку сайта.

Далее, если спрайтов у нас немного (1–2 картинки), то общее время загрузки сайта, скорее всего, возрастет. Это связано с тем, что браузер не сможет открыть, как минимум, 6–7 дополнительных соединений (к хостам, где расположена статика) и загрузить все исходные картинки параллельно, а не последовательно. При небольшой сетевой задержке это может оказать решающее воздействие.

Проблемы при использовании

Даже положившись на то, что спрайты поддерживаются (почти) всеми браузерами на данный момент, все равно остается достаточно много вопросов, которые они не только не решают, а скорее, сами создают. Во-первых, это проблемы при использовании иконок для списка. Как я указывал в своей статье, в таком случае необходимо располагать маленькие картинки «лесенкой», но, в общем случае, это увеличивает размер получившейся картинки на 20–30%.

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

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

Все совсем плохо?

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

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

Шаг за шагом

С развитием техник data:URL (в том числе, кроссбраузерное их применение) наиболее логичным выходом из сложившейся ситуации будет следующее:

  • Верстальщик создает рабочую версию макета сайта, не прибегая к помощи CSS Sprites (на каждый элемент одна фоновая картинки).
  • Веб-технолог внедряет кодирование картинок в base64 (+mhtml) в CSS-файл(ы) на этапе их загрузки на боевой сайт.
  • Веб-программист обеспечивает для ряда «старых» браузеров загрузку версии без использования data:URL.

Чем это хорошо? Верстальщик не думает лишний раз, что и как ему расположить и нарезать: эти операции уже включено в процесс публикации сайта, автоматизированы и максимально адаптированы под пользователей.

Чем это плохо? В общем случае, загрузка страницы не ускорится, а даже может замедлиться, потому что фоновые картинки (включенные через data:URL) будут грузиться в один поток, а не в несколько при обычном использовании спрайтов. Если фоновых картинок достаточно много (несколько десятков Кб), то это окажется существенным. При небольшом их объеме (до 10Кб) будет заметно явное ускорение.

Алгоритмическое кеширование

Для случаев больших объемов вышеуказанных подход не подходит. Точнее, он был бы просто идеальным, если бы все браузеры могли загружать CSS-файлы в несколько потоков (возможно, есть решение, позволяющее максимально быстро начать множественную загрузку файлов стилей) это позволило бы разбить фоновые картинки на группы по 5–10Кб и загружать их максимально параллельно.

Разбиение CSS-файла на основной и ряд дополнительных, содержащих фоновые картинки также позволит решить проблему кеширования (CSS-объявления будут кешироваться, фактически, независимо от самих картинок, что не происходит в случае одного монолитного файла). Однако, пока мне не известен механизм, который позволял бы наиболее эффективно использовать данный подход. Загрузку нескольких CSS-файлов в один поток я не рассматриваю в качестве реальной альтернативы использованию CSS Sprites.

Под алгоритмическим кешированием я имею в виду подход, описанный в соответствующей статье: он, по сути, является логическим продолжением техники предзагрузки картинок через new Image(), однако, оперирует данными об общем размере картинок и всей страницы. Как применение его в данном случае я могу порекомендовать нарезать CSS Sprites на 6–8 частей (не меньше 5Кб каждая, при малом объеме картинок их все же лучше включать в CSS-файл).

Например, пусть у вас есть графическое меню, пункты которого изменяются при наведении. Всего пунктов 6, каждая картинка занимает 3Кб (всего 12 картинок). Так вот, вместо создания монолитного спрайта на 36КБ я предложил бы в данном случае создать 6 спрайтов по 6Кб (на каждый пункт меню), добавить их в предзагрузку сразу в head странице. Это упростит их возможное изменение, ускорит «визуальную» загрузку (отдельные картинки появятся быстрее), и крайне слабо отразится на общей скорости загрузки (она немного упадет, ибо нужно будет открыть по 2 соединения к 3 хостам (в идеальном случае)). В случае же повторного захода скорость прохождения 304 ответов не влияет на отображения страницы.

Заключение

Я надеюсь, данная статья заставит немного задуматься всех, кто уже активно использует спрайты. Все, кто еще не знаком с этой техникой, советую относиться к ней с осторожностью: иногда можно и переборщить. Те же, кто заботится о максимальной производительности своих страниц, я надеюсь, почерпнут несколько полезных советов.

Массовое использование data:URL не за горами, но пока общая технология недостаточно обкатана, чтобы включать ее в процесс разработки веб-сайтов. Однако, это будущее уже рядом, будьте наготове :)

Читать дальше

Все комментарии (habrahabr.ru)