Является ли встраивание данных фонового изображения в CSS как Base64 хорошей или плохой практикой? - PullRequest
467 голосов
/ 14 июля 2009

Я смотрел на источник пользовательского скрипта greasemonkey и заметил следующее в их css:

.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}

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

  1. Это уменьшит количество HTTP-запросов при загрузке страницы, что повысит производительность
  2. Если CDN отсутствует, это уменьшит объем трафика, генерируемого с помощью файлов cookie, отправляемых вместе с изображениями
  3. CSS-файлы могут быть кэшированы
  4. CSS-файлы могут быть GZIPPED

Учитывая, что IE6 (например) имеет проблемы с кешем для фоновых изображений, похоже, это не самая плохая идея ...

Итак, это хорошая или плохая практика, почему бы вам НЕ использовать ее и какие инструменты вы бы использовали для кодирования изображений base64?

обновление - результаты тестирования

  • тестирование с изображением: http://fragged.org/dev/map-shot.jpg - 133.6Kb

  • тестовый URL: http://fragged.org/dev/base64.html

  • выделенный файл CSS: http://fragged.org/dev/base64.css - 178,1Kb

  • Серверная кодировка GZIP

  • полученный размер отправлен клиенту (YSLOW тестирование компонентов): 59,3Kb

  • Сохранение данных, отправленных клиентскому браузеру: 74.3Kb

Хорошо, но это будет немного менее полезно для небольших изображений, я думаю.

ОБНОВЛЕНИЕ: Брайан МакКуэйд, инженер-программист из Google, работающий над PageSpeed, заявил на ChromeDevSummit 2013, что data: uris в CSS считается анти-паттерном, блокирующим рендеринг, для предоставления критического / минимального CSS во время своего выступления #perfmatters: Instant mobile web apps. Смотрите http://developer.chrome.com/devsummit/sessions и имейте это в виду - фактический слайд

Ответы [ 12 ]

162 голосов
/ 14 июля 2009

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

до генерации кодировки base64:

55 голосов
/ 25 марта 2011

Этот ответ устарел и не должен использоваться.

1) Средняя задержка намного выше на мобильных устройствах в 2017 году. https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network

2) мультиплексы HTTP2 https://http2.github.io/faq/#why-is-http2-multiplexed

«URI данных» определенно следует учитывать для мобильных сайтов. HTTP-доступ по сотовым сетям имеет большую задержку на запрос / ответ. Так что есть некоторые случаи использования, когда вставка изображений в виде данных в шаблоны CSS или HTML может быть полезна для мобильных веб-приложений. Вы должны оценивать использование в каждом конкретном случае - я не сторонник того, чтобы URI данных использовались повсеместно в мобильном веб-приложении.

Обратите внимание, что мобильные браузеры имеют ограничения на общий размер файлов, которые могут быть кэшированы. Ограничения для iOS 3.2 были довольно низкими (25 КБ на файл), но увеличиваются (100 КБ) для более новых версий Mobile Safari. Поэтому обязательно следите за общим размером файла при включении URI данных.

http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

23 голосов
/ 14 июля 2009

Если вы ссылаетесь на это изображение только один раз, я не вижу проблемы в том, чтобы вставить его в ваш файл CSS. Но как только вы используете более одного изображения или вам нужно ссылаться на него несколько раз в вашем CSS, вы можете рассмотреть возможность использования одной карты изображений, вместо этого вы можете обрезать свои отдельные изображения из (см. CSS Sprites ).

21 голосов
/ 07 июля 2011

Я хотел бы предложить две отдельные таблицы стилей: Один с вашими обычными определениями стилей, а другой содержит ваши изображения в кодировке base64.

Вы, конечно, должны включить базовую таблицу стилей перед таблицей стилей изображения.

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

20 голосов
/ 16 января 2012

Base64 добавляет около 10% к размеру изображения после GZipped, но это перевешивает преимущества, когда дело доходит до мобильных устройств. Поскольку в отношении адаптивного веб-дизайна наблюдается общая тенденция, настоятельно рекомендуется.

W3C также рекомендует этот подход для мобильных устройств, и если вы используете конвейер ресурсов в рельсах, это функция по умолчанию при сжатии CSS

http://www.w3.org/TR/mwabp/#bp-conserve-css-images

4 голосов
/ 04 августа 2011

Я не согласен с рекомендацией создавать отдельные CSS-файлы для нередакторных изображений.

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

3 голосов
/ 01 февраля 2014

Вы можете закодировать его в PHP:)

<img src="data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>">

Or display in our dynamic CSS.php file:

background: url("data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>");

1 That’s sort of a “quick-n-dirty” technique but it works. Here is another encoding method using fopen() instead of file_get_contents():

<?php // convert image to dataURL
$img_source = "feed-icon.gif"; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);
?>

Источник

3 голосов
/ 25 июня 2013

Я пытался создать онлайн концепцию инструмента анализа CSS / HTML:

http://www.motobit.com/util/base64/css-images-to-base64.asp

Может:

  • Загрузка и анализ файлов HTML / CSS, извлечение элементов href / src / url
  • Обнаружение сжатия (gzip) и данных о размере в URL
  • Сравнить исходный размер данных, размер данных base64 и сжатый размер данных base64
  • Преобразование URL (изображения, шрифта, CSS, ...) в схему URI данных base64.
  • Подсчет количества запросов, которые могут быть сэкономлены с помощью URI данных

Комментарии / предложения приветствуются.

Антонин

3 голосов
/ 11 февраля 2011

В моем случае это позволяет мне применять таблицу стилей CSS, не беспокоясь о копировании связанных изображений, поскольку они уже встроены внутрь.

2 голосов
/ 31 июля 2013

Подводя немного для пользователей Sublime Text 2, есть плагин, который дает код base64, который мы загружаем в ST.

Вызывается Image2base64: https://github.com/tm-minty/sublime-text-2-image2base64

PS: Никогда не сохраняйте этот файл, сгенерированный плагином, потому что он перезапишет файл и уничтожит.

...