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

小开

最佳答案

这是一种好的做法吗? 有什么理由可以避免这种做法吗？

这是一个很好的实践，通常只有非常小的 CSS 图像将要一起使用(如 CSS 精灵) ，当 IE 兼容性无关紧要，保存请求比缓存更重要。

它有许多明显的缺点:

在 IE6和 IE7中根本无法工作。
仅适用于在 IE8中可以达到32k 的大小资源。这是在 base64编码之后应用的限制。换句话说，不超过32768个字符。
它保存了一个请求，但却膨胀了 HTML 页面！并使图像无法访问。每次加载包含页或样式表时都会加载它们。
Base64编码使图像大小增加了33% 。
如果使用 gzip 压缩的资源提供服务，那么 data:映像几乎肯定会对服务器的资源造成可怕的压力！图像传统上都是 CPU 密集型的压缩，几乎没有减少大小。

小开

这不是个好习惯。有些浏览器不支持数据 URI (如 IE6和 IE7)或支持有限(如 IE8的32KB)。

有关数据 URI 缺点的完整细节，请参阅 Wikipedia 的这篇文章:

数据 URI 方案

缺点

数据 URI 不会与其所包含的文档(例如 CSS 或 HTML 文件)分开缓存，因此每次重新下载所包含的文档时，数据都会被下载。

每次进行更改时，必须对内容进行重新编码和重新嵌入。

Internet Explorer 版本7(截至2011年1月约占15% 的市场份额) ，缺乏支持。

Internet Explorer 8将数据 URI 的最大长度限制为32kb。

数据包含在一个简单的流中，许多处理环境(比如 web 浏览器)可能不支持使用容器(比如 multipart/alternative或者 message/rfc822)来提供更复杂的元数据、数据压缩或者内容协商。

Base64编码的数据 URI 的大小比它们的二进制等价物大1/3。(然而，如果 HTTP 服务器使用 gzip 压缩响应，这个开销将降低到2-3%)

数据 URI 使得安全软件过滤内容变得更加困难。

小开

我更倾向于使用 CSS Sprites 来组合图像并节省请求。我从来没有尝试过 base64技术，但它显然不工作在 IE6和 IE7。这也意味着，如果任何图像的变化，然后你必须重新交付整个丢失，除非你有多个 CSS 文件，当然。

小开

我对一般的最佳实践一无所知，但我个人不愿意看到这种事情，如果我能帮助它。:)

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

您认为目前有太多的请求发送到服务器是否有原因？

小开

我使用 data-uri 已经有一个月了，但我不再使用它们，因为它们让我的样式表变得非常庞大。

Data-uri 可以在 IE6/7中工作(只需要向这些浏览器提供一个 < strong > mhtml 文件)。

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

很高兴我们有这种技术可用，但我不会在未来使用它太多。不过我还是建议你试试，这样你就知道了

小开

这里的常见答案似乎表明，出于一系列合理的原因，这种做法是不必要的。然而，所有这些似乎都忽略了现代应用程序的行为和构建过程。

设计一个简单的过程来遍历一个文件夹图像并生成一个包含该文件夹所有图像的 CSS 并不是不可能的(实际上也很容易)。

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

当然，是黑客。毫无疑问。就像精灵是黑客一样。在完美的世界里，这是不需要的，直到那时，如果你需要修正的是:

页面上有多个图像，不容易“喷绘”。
往返于服务器之间是一个实际的瓶颈(想想移动设备)。
速度(到毫秒级别)对于您的用例来说是非常重要的。
你不关心 IE5和 IE6(如果你想让网络向前发展，你就应该关心)。

我的观点。

小开

我建议对于经常使用的小图片使用它，例如网络应用程序的常见图标。

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

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