我应该在CSS或HTML中将图像作为data / base64嵌入吗


130

为了减少服务器上的请求数量,我将一些图像(PNG和SVG)作为BASE64直接嵌入到CSS中。(在构建过程中自动执行)

像这样:

background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAFWHRTb2Z0d2FyZQBBZG etc...);

这是一个好习惯吗?有什么理由可以避免这种情况?是否有一些不支持数据URL的主流浏览器?

额外的问题:对CSS和JS这样做也有意义吗?


1
不再有使用IE7的人了,所有缺点都有一个非常好的优点-更少的图像文件需要管理!例如,如果您需要为树组件绘制特殊线条,然后将小肘图像与repeat-x或repeat-y结合嵌入css本身,则无需确保多余的图像文件在正确的位置(很少)该用例的开销)
DaveAlger 2013年

Answers:


153

这是一个好习惯吗?有什么理由可以避免这种情况?

这是一个好习惯,通常仅适用于在IE兼容性无关紧要时将一起使用的非常小的CSS图像(如CSS Sprites),并且保存请求比可缓存性更为重要。

它有许多明显的缺点:

  • 在IE6和7中根本不起作用。

  • 在IE8中仅适用于最大32k的资源。这是在base64编码之后适用的限制。换句话说,不能超过32768个字符。

  • 它保存了一个请求,但是却使HTML页面肿!并使图像不可缓存。每当包含页面或样式表加载时,它们就会加载。

  • Base64编码使图像大小膨胀了33%。

  • 如果在压缩后的资源中提供data:图像,几乎可以肯定会对服务器资源造成巨大的压力!传统上,图像压缩需要占用大量CPU资源,而尺寸却很少减少。


2
@meo有趣的一点。我希望这对gzip性能不利,因为图像通常已经非常优化地压缩了。压缩它们将使CPU的空间消耗惨重,无法获得个位数的百分比增长。尝试gzip解压缩JPG文件,您将明白您的意思。我将其编辑为答案
Pekka

1
我知道gzip压缩图像不是要走的路。但是我在想,它可能在base 64上更有效。尤其是当源中包含多个映像时。
meo

2
@meo nope,在任何情况下它都不会在base64上更有效,因为基础模式仍然是恰好以base64表示法表示的压缩图像数据。
Pekka

1
@meo啊,我明白了。那根本无法在IE中使用,并且存在相同的可缓存性问题:您保存了一个请求,但是每个页面请求的大小都会增加。通常将所有内容压缩到一个CSS和一个JS文件中可能要好得多
-Pekka

5
不是当你在一个CSS文件中嵌入图像的问题表示臃肿的HTML页面。
Daniel Beardsley

38

出于一系列合法的原因,此处的常见答案似乎表明不需要这样做。但是,所有这些似乎都忽略了现代应用程序的行为和构建过程。

设计一个简单的过程来遍历文件夹图像,并使用该文件夹的所有图像生成单个CSS,这并非没有可能(实际上非​​常容易)。

此css将被完全缓存,并将大大减少到服务器的往返行程,这是@MemeDeveloper正确建议的,这是最大的性能问题之一。

当然,这是骇客。毫无疑问。和精灵一样,都是骇客。在完美的世界中,这是不需要的,直到那时,如果您需要解决的问题是一种可能的做法:

  1. 包含多个不容易“存储”的图像的页面。
  2. 服务器往返是一个实际的瓶颈(认为是移动设备)。
  3. 速度(以毫秒为单位)对于您的用例确实非常重要。
  4. 您并不关心IE5和IE6(如果希望网络向前发展,则应该这样做)。

我的看法。


4
应该对此进行投票以获得更多关注。其他答案有点过时了-他们谈论IE6的时候,IE8却有些过时了……(并感谢您)
Hertzel Guinness 2014年

11

这不是一个好习惯。某些浏览器不支持数据URI(例如IE 6和7)或支持受到限制(例如IE8为32KB)。

另请参阅此Wikipedia文章,以获取有关Data URI缺点的完整详细信息:

缺点

  • 数据URI不会从其包含的文档(例如CSS或HTML文件)中单独缓存,因此每次重新下载包含的文档时都会下载数据。
  • 每次进行更改时,都必须重新编码内容并重新嵌入内容。
  • 版本7的Internet Explorer(截至2011年1月约占市场的15%)缺乏支持。
  • Internet Explorer 8将数据URI的最大长度限制为32 KB。
  • 数据作为简单流包含在内,许多处理环境(例如Web浏览器)可能不支持使用容器(例如multipart/alternativemessage/rfc822)来提供更大的复杂性,例如元数据,数据压缩或内容协商。
  • Base64编码的数据URI的大小比其二进制等效文件大1/3。(但是,如果HTTP服务器使用gzip压缩响应,则此开销将减少到2-3%)
  • 数据URI使安全软件更难以过滤内容。

3
每次请求都重新下载CSS吗?那是新的!另外,如果您一生中都存档过文件,您会注意到压缩率不是2-3%!如果我没记错的话,我首先在yahoo.com上看到了这种技术。……显然不是好习惯!
StefanNch

@StefanNch并不是这个意思。在摘录中,“包含文档”是指css文件。
Christophe

9

我使用data-uri已有大约一个月的时间,而Ive刚刚停止使用它们,因为它们使我的样式表绝对庞大。

Data-uri确实可以在IE6 / 7中工作(您只需要向这些浏览器提供mhtml文件即可)。

使用data-uri的好处是,下载样式表后立即渲染了我的背景图片,而不是我们逐渐看到的渐进式加载

很高兴我们可以使用这种技术,但是将来我不会使用太多。我确实建议您尝试一下,只是为了让您自己知道


3

我更倾向于使用CSS Sprite合并图像并按要求保存。我从未尝试过使用base64技术,但是它显然在IE6和IE7中不起作用。这也意味着,如果任何图像发生变化,那么除非您有多个CSS文件,否则您必须重新传输全部丢失的图像。


我已经有了精灵,我想知道是否可以使用该方法进一步优化它。
meo

2

我对一般的最佳实践一无所知,但是我可以帮助我,但我不希望看到这种事情。:)

Web浏览器和服务器内置了全部缓存内容,因此我认为最好的选择就是让您的服务器告诉客户端缓存图像文件。除非您在页面上加载非常小的图像,否则我不会认为多个请求的开销是一件大事。浏览器通常将使用相同的连接来请求大量文件,因此不会建立新的网络连接,因此,除非通过HTTP标头提供的流量与图像文件的大小相比是可观的,否则我不会担心太多请求。

您是否有理由认为目前有太多请求发送到服务器?


4
如果您关心性能问题,那么请求数量是最大性能问题之一,这是尝试解决的第一件事。请参阅yahoo的take developer.yahoo.com/performance/rules.html “减少组件数量反过来又减少了呈现页面所需的HTTP请求数量。这是提高页面速度的关键。”
MemeDeveloper 2013年

0

我建议将其用于经常使用的微小图像,例如Web应用程序的常用图标。

  • 很小,因为Base64编码增加了大小
  • 经常使用,因为这证明更长的初始加载时间是合理的

当然,必须牢记旧版浏览器的支持问题。使用框架的功能来自动内嵌图像的数据URL(例如GWT的ClientBundle)或至少使用CSS类,而不是直接将其直接添加到元素的样式中,也是一个好主意。

此处收集了更多信息:http : //davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.