HTTP 请求与文件大小？答案

【问题标题】：HTTP Requests vs File Size?HTTP 请求与文件大小？
【发布时间】：2020-06-04 22:00:38
【问题描述】：

如果这意味着页面大小下降，那么在什么时候拥有更多 HTTP 请求会更好？例如，如果我有一个 20KB 的图像，我需要减小多少大小才能更有意义地使用两个图像？

【问题讨论】：

请求实际上是几百字节。没有理由将图像分解以减小大小，因为各部分大小的总和将大于原始大小（每个文件都包含一个标题，这会占用空间）。
请求越少越好。 1 个 20 KB 的 rq 比 2 个 10KB + 10KB 的 rq 表现更好
@dotoree 在某些情况下，您可以通过将图像拆分为多个图像文件来大大减小图像的大小。这就是我要问的。我不是将 20KB 拆分为两个 10KB 文件，而是将其拆分为两个 4KB 文件（例如）。在什么时候拥有多个文件会更好？
@MikeH 你完全走错了路。有一些完全相反的模式，请参阅w3schools.com/css/css_image_sprites.asp All images in one！
@dotoree 我知道并使用 css sprites。如果它更容易，我可以扭转这种情况。假设您有两个 4KB 的图像。在什么时候将这两个图像组合起来不再值得。当单张图片是20KB？更多的？少一点？

【解决方案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 这样更有价值的东西，或其他不可分割的图像。这会减慢页面的整体加载时间。

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

我怀疑你会发现一个properly compressed PNG 不会大于构成同一图像的两个 PNG 的总大小。

_{（来源：josh3736.net）}
（1027 字节）

_{（来源：josh3736.net）}

_{（来源：josh3736.net）}
（730 + 809 = 1539 字节）

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

【讨论】：

感谢您的回复。我确实想说有些地方可以缩小文件大小。例如，最开始让我思考这个问题的情况。我需要一个渐变背景，它变得透明并在顶部和底部逐渐变细。我可以使用一张大图像，或者为大部分渐变制作一个 1px 高的图像，并为末端制作单独的图像。这将减少 80% 的大小，但会增加 2 个 HTTP 请求。此外，如果答案真的不是，理论上我可以将网站中的每张图片放入一个 CSS Sprite 中，并且只让一张图片调用一个页面。
@MikeH，渐变背景是他们自己的挑战，但为什么不skip images altogether？无论如何，这就是我说“一般”的原因——在某些情况下，您需要单独的图像，例如在两个轴上重复的背景。（在一个轴上重复的背景仍然可以被精灵化——对于 x 重复，在 y 轴上堆叠背景并将背景拉伸到输出图像的宽度。这就是 SmartSprites 的做法。）跨度>
当然，我并不是建议你将每一个图像都放入一个精灵——那太傻了。有一个平衡行为来保持 HTTP 往返效率和客户端缓存寿命。换句话说，将可能更改的图像放入精灵中会适得其反，因为即使只有一小部分更改，也必须重新下载整个内容。我的经验法则是设计元素/小图标（通常是 PNG）进入 sprite，而照片（通常是 JPEG）是它们自己的文件。
我也了解 CSS 渐变。在我解释的情况下，在这种情况下不可能使用 CSS 渐变同时使 IE 看起来不错。在你说只是使用图像让 IE 依赖之前，我不得不回去再次问我原来的问题。不过，这只是一个例子。为什么每个人都认为我对我的问题的基本原则一无所知？是的，需要保持平衡。这就是我的问题的重点——找出天平尖端的位置。
@mikeh 可能在某些极端情况下，两个图像比一个图像更有效，但我的猜测是它只会在低延迟的环境中成立。找出答案的方法是在不同的带宽和延迟场景中使用一些精心设计的图像进行测试。不要忘记考虑慢启动也会使事情复杂化。

【解决方案2】：

乔希回答的结论并没有真正改变。考虑到"Mobile Network Experience Report Jan. 2020"，延迟减少了大约 30%（从 80 毫秒到大约 55 毫秒），但对于评分最低的运营商而言，平均下载速率（移动）已增加到 23 MB/s。

因此，我们为 2019 年评分最低的美国移动运营商得出了这个理论数字：

1x 20 kB files:  55ms latency + 7ms transfer time = 62ms
2x 4 kB files:  110ms latency + 2 ms transfer time = 112ms

【讨论】：