40

所以我正在用 php 做一些事情，我必须从 sql 数据库中获取我的图像，它们将以 base64 编码。显示这些图像的速度至关重要，因此我试图弄清楚将数据库数据转换为图像文件然后将其加载到浏览器中是否会更快，或者只是回显原始 base64 数据并使用：

<img src="data:image/jpeg;base64,/9j/4AAQ..." />

FireFox 和其他 Gecko 浏览器均支持该功能。

所以回顾一下，传输实际图像文件或base64代码会更快吗？使用ajax加载图像时需要更少的http请求吗？

图像总共不超过 100 像素。

4

10 回答 10

37
  • Base64 编码使文件更大，因此传输速度更慢。
  • 通过在页面中包含图像，每次都必须下载它。外部图像通常只下载一次，然后由浏览器缓存。
  • 它不兼容所有浏览器
于 2009-02-07T01:47:53.947 回答
26

好吧，我不同意你们中的任何人。在某些情况下，您必须加载越来越多的图像。并非所有页面都包含 3 张图片。实际上，我正在一个需要加载 200 多张图片的网站上工作。当 100000 个用户在一个负载非常大的网站上请求 200 张图片时会发生什么。服务器的磁盘，返回图像应该崩溃。更糟糕的是，您必须向服务器发出如此多的请求，而不是使用 base64。对于这么多缩略图，我更喜欢 base64 表示，预先保存在数据库中。我在http://www.stoimen.com/2009/04/23/when-you-should-use-base64-for-images/找到了解决方案和强有力的论据. 这家伙真的是那种情况，做了一些测试。我印象深刻，也进行了测试。现实就像它说的那样。对于在一页中加载的如此多的图像，来自服务器的一个响应确实很有帮助。

于 2009-04-23T05:52:08.253 回答
5

如果不修改，为什么要一次又一次地重新生成图像。假设，即使基于 1000 个不同的条件要显示 1000 个不同的可能图像，我仍然认为磁盘上的 1000 个图像更好。请记住，基于磁盘的图像可以由浏览器缓存并节省带宽等。

于 2009-02-07T09:26:58.713 回答
3

不要认为data://在 IE7 或更低版本中有效。

当请求图像时，您可以将其保存到文件系统，然后从那时起提供该图像。如果数据库中的图像数据发生更改，则只需删除该文件。也可以从另一个域（例如 img.domain.com）提供它。您可以从您的网络服务器免费获得上次修改或电子标签的所有好处，而无需启动 PHP，除非您也需要。

如果您使用的是 apache：

# If the file doesn't exist:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(image123).jpg$ makeimage.php?image=$1
于 2009-02-07T01:57:33.333 回答
3

为了回答最初的问题，我进行了一个测试，以 96 ppi 测量 400x300 像素的 jpeg 图像：

base64ImageData.Length
177732

bitmap.Length
129882
于 2013-12-16T19:47:02.840 回答
3

这是一个非常快速和简单的解决方案。虽然图像大小会增加 33% 左右，但使用 base64 会显着减少 http 请求的数量。

Google 图像和 Yahoo 图像使用 base64 并内联提供图像。检查源代码，你会看到它。

当然，这种方法也有缺点，但我相信收益大于成本。我发现的一个缺点是慢速设备。例如，在 iPhone 3GS 中，由 google 图像提供的图像渲染速度非常慢，因为图像是从服务器 gzip 压缩的，并且必须在浏览器中解压缩。因此，如果客户的设备速度较慢，他在渲染图像时会受到一点影响。

于 2014-02-15T17:07:40.543 回答
3

我曾经使用过一次或两次 base64 图像作为图标（10x10 像素左右）。

Base64 图像优点：

  • 紧凑 - 你有一个文件。同样，如果文件被压缩，base64 图像几乎被压缩到普通图像的大小。
  • 在单个请求中检索页面。

Base64 图像缺点：

  • 实际上，您可能需要在包含图像的所有页面上使用脚本引擎（例如 PHP）。
  • 如果图像更改，则必须重新下载所有缓存的页面。
  • 因为图像是内联的，所以不能使用 CDN 或静态内容 Web 服务器。

普通图像优点：

  • 如果您使用 SPDY 协议，至少理论上，页面 + 图像 + CSS 也将通过单个请求加载。
  • 您可以在图像上设置过期时间，因此将从浏览器缓存内容。
于 2016-02-27T08:17:43.277 回答
2

一般来说，使用 base64 编码会使字节大小增加约 1/3。因此，您将不得不将 1/3 字节从数据库移动到服务器，然后将这些额外的 1/3 字节通过线路移动到浏览器。

当然，随着图像大小的增长，所提到的开销也会成比例地增加。

话虽如此，我认为将文件更改为数据库中的字节表示形式并传输它们是个好主意。

于 2009-02-07T01:50:37.920 回答
2

回答 OP 问题。作为静态文件，直接通过磁盘通过网络服务器。它们只有 100 像素，非常适合 Web 服务器的内存缓存。几乎所有的 Web 服务器都有大量的信息、缓存策略、配置、操作方法。

Infact - 就用户体验（您所指的图像速度）而言，最佳选择是使用支持 CDN 的对象存储。时期。

作为静态存储选择的“数据库”非常昂贵——就所有开销处理、数据库负担、财务和技术债务而言。

几件事，来自几个答案

Google 图像和 Yahoo 图像使用 base64 并内联提供图像。检查源代码，你会看到它。

不，他们绝对不会。图像主要来自静态文件“网络服务器”，特别是 gstatic.com：例如https://ssl.gstatic.com/gb/images/p1_2446527d.png

紧凑 - 你有一个文件。同样，如果文件被压缩，base64 图像几乎被压缩到普通图像的大小。

所以实际上，一点优势都没有，加上需要压缩的处理？

在单个请求中检索页面。同样，多个并行请求而不是单个更大的负载。

当 100000 个用户在一个负载非常大的网站上请求 200 张图片时会发生什么。服务器的磁盘，返回图像应该崩溃。您仍将发送相同数量的数据，但连接时间更长，并且会给您的数据库带来压力。其次，工厂站点运行具有 100000 个并发连接的可能性......即使是这样，如果您在单个服务器上运行这一切，您就是一个愚蠢的管理员。

通过将图像（二进制 blob 或 base64）存储在数据库中，您所做的一切都会为数据库增加巨大的开销。要么，你有大量的 RAM，要么你通过数据库的查询无论如何都会从磁盘上掉下来。而且，如果您确实拥有如此无限的 RAM，那么从 Ramdisk 上提供 bin 图像 - 理想情况下，通过替代专用的、轻量级的 Web 服务器静态文件和缓存优化，在子域上配置，将是最快、最轻的负载！

远期规划？到目前为止，您只能扩大规模，并且扩大数据库的成本很高（相对而言）。你说的磁盘再次将“sp

在这种情况下，您为 100000 个并发用户提供 100 张图像，您的图像服务应该是 CDN 对象存储的域。

于 2020-03-21T10:16:54.437 回答
0

如果您想要最快的速度，那么您应该在上传/修改它们时将它们写入磁盘，并让网络服务器提供静态文件。Rojoca 的建议也很好，因为它们最大限度地减少了 php 的调用。从另一个域提供服务的另一个好处是（大多数）浏览器将并行发出请求。

除此之外，当您查询数据时，请检查它是否上次修改，然后将其写入磁盘并从那里提供服务。您需要确保尊重 If-Modified-Since 标头，以免不必要地传输数据。

如果您无法写入磁盘或其他缓存，那么将其作为二进制数据存储在数据库中并将其流出是最快的。此时调整缓冲区大小将有所帮助。

于 2009-02-07T02:19:26.037 回答