performance - HTTP 请求与文件大小？

Question

如果这意味着页面大小下降，什么时候有更多的 HTTP 请求更好？例如，如果我有一个 20KB 的图像，在使用两个图像更有意义之前我必须减少多少大小？

Answer 1

实际的答案是从不，尤其是当您谈论的数据量相对较小时，例如一两千字节。

网页性能的真正敌人不是传输的字节数；相反，它是网络延迟。让我们以您的示例为例，考虑一个 5 Mb/s 的连接(美国的平均连接速度略高于此)，到您的服务器的 ping 时间为 80 毫秒:

1x 20 kB files:  80ms latency + 31ms transfer time = 111ms
2x 4 kB files:  160ms latency + 13ms transfer time = 173ms

在所有其他变量都相同的情况下，这种“优化”只花费了 至少 62 毫秒。在现实世界中，我敢打赌，由于额外的服务器负载等原因，性能会更差。

还要考虑到您现在正在使用浏览器将发出的有限数量的并行请求中的一个额外请求(在 2 到 8 之间，具体取决于浏览器)用于图像的一半，而不是像脚本、CSS 这样更有值(value)的东西, 或其他非 spritable 图像。这会减慢页面的整体加载时间。

此外，我怀疑您的整个前提都存在缺陷。通常，将图像拆分为两个文件并不能真正减小整体文件大小，因为每种图像容器格式都有 header 数据；例如，PNG 文件在任何实际图像数据之前至少有 57 个字节的开销。此外，额外的 HTTP 请求意味着额外的 ± 800-900 字节的网络开销。

我想你会找到那个 properly compressed PNG 不会大于构成同一图像的两个 PNG 的总大小。

_{(来源:josh3736.net)}
(1027 字节)

<sub>(来源:josh3736.net)

(来源:josh3736.net)</sub>
(730 + 809 = 1539 字节)

即使第一个 PNG 具有 150x100 像素的“死”透明空间，它也比表示相同图像的两个 PNG 小 33%。 (请忽略我无法在此处正确对齐 <img> 标签以使两个示例看起来相同。)