我应该将图像作为数据/ base64嵌入CSS或HTML中

时间:2011-03-10 10:02:35

标签: html css base64

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

像这样:

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

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

奖金问题: 为CSS和CSS执行此操作是否有意义? JS也呢?

7 个答案:

答案 0 :(得分:153)

  

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

这种做法通常只适用于IE兼容性无关紧要的非常小的CSS图像(如CSS精灵),保存请求比可缓存性更重要。

它有许多值得注意的缺点:

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

  • 仅适用于资源up to 32k in size in IE8。这是base64编码后适用的限制。换句话说,不超过32768个字符。

  • 它会保存一个请求,但会改变HTML页面!并使图像无法缓存。每次加载包含页面或样式表时都会加载它们。

  • Base64编码使图像尺寸膨胀33%。

  • 如果在gzip压缩资源中提供服务,data:图像几乎肯定会对服务器资源造成严重压力!传统上,图像在压缩时非常耗费CPU,而且尺寸几乎没有减少。

答案 1 :(得分:34)

这里的常见答案似乎表明,由于一系列合理的原因,这不是必需的。 但是,所有这些似乎都忽略了现代应用程序的行为和构建过程。

设计一个简单的过程并不是不可能(实际上非​​常简单),它将遍历文件夹图像,并生成一个包含该文件夹所有图像的CSS。

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

当然,这是黑客。毫无疑问。像精灵一样是一个黑客。在完美的世界中,这是不需要的,在此之前,如果您需要解决的是:

  1. 包含多张图片的页面,这些图片不易被“喷涂”。
  2. 往返服务器是一个真正的瓶颈(想想移动)。
  3. 速度(以毫秒为单位)对您的用例来说非常重要。
  4. 关于IE5和IE6,你不关心(如果你想让网络继续前进的话)。
  5. 我的观点。

答案 2 :(得分:11)

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

有关数据URI缺点的完整详细信息,请参阅此维基百科文章:

  

<强>缺点

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

答案 3 :(得分:9)

我正在使用data-uri大约一个月,我刚刚停止使用它们,因为它们使我的样式表非常庞大。

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

我使用data-uri获得的一个好处是,我的背景图像在下载样式表后立即呈现,而不是我们看到的逐渐加载

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

答案 4 :(得分:3)

我更倾向于使用CSS Sprites来合并图像并节省请求。我从来没有尝试过base64技术,但它显然在IE6和IE7中不起作用。同时也意味着如果任何图像发生变化,那么除非你有多个CSS文件,否则你必须重新传输整个丢失的文件。

答案 5 :(得分:2)

我不知道一般的最佳实践,但如果我能帮助它,我不希望看到那种事情。 :)

Web浏览器和服务器内置了大量的缓存内容,所以我认为最好的办法就是让服务器告诉客户端缓存图像文件。除非你在页面上有很多非常小的图像,否则我不会认为多个请求的开销是一个大问题。浏览器通常会使用相同的连接来请求大量文件,因此没有建立新的网络连接,所以除非通过HTTP标头的流量与图像文件的大小相比是显着的,否则我不会担心多个请求太多

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

答案 6 :(得分:0)

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

  • 微小,因为Base64编码增加了大小
  • 经常使用,因为这证明了较长的初始加载时间

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

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